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L  INTRODUCTION 


Retention  of  "corporate  knowledge"  is  vital  to  any  large  organization.  The  United 
States  Marine  Corps  (USMC),  as  well  as  all  other  military  services  in  the  United  States, 
constantly  faces  the  loss  of  critical  skills  and  leadership  as  top  quality  Marines  choose  to 
leave  the  service  for  a  variety  of  reasons.  Policymakers  must  decide  what  actions  are 
possible  and  necessary  to  keep  well-trained  Marines  motivated  to  stay  in  the  service. 
Toward  this  end,  the  USMC  has  initiated  the  USMC  Exit  and  Retention  Censuses  to  be 
implemented  beginning  in  Fiscal  Year  1999  and  continuing  indefinitely  on  an  annual  basis. 
The  initiative  takes  advantage  of  contemporary  technology,  by  placing  the  survey 
instrument  on  the  Internet  as  the  vehicle  for  data  collection.  This  thesis  produces  a 
database  design  and  implementation  to  facilitate  understanding,  analysis,  and 
administration  of  the  collected  data  as  well  as  management  of  the  census  questionnaires 
throughout  the  lifecycle  of  the  censuses. 

A.  BACKGROUND 

The  USMC  Exit  and  Retention  Censuses  (or  surveys)  will  ask  over  200  questions 
of  as  many  Marines  as  possible  every  year.  The  intention  as  stated  by  the  program 
sponsor,  Manpower  and  Reserve  Affairs  (M&RA),  Headquarters  USMC  (HQMC),  is  to 
have  100  percent  participation,  less  general  officers,  officer  candidates,  and  recruits. 
Marines  exiting  the  service  must  complete  the  Exit  Census  prior  to  being  fully  discharged. 
All  others  are  to  complete  the  Retention  Census  on  an  annual  basis.  Both  are  conducted 
via  the  Marine  OnLine  (MOL)  website  on  the  World  Wide  Web.  The  effort  is  intended  to 
harness  contemporary  information  technology  to  make  the  surveys  easily  accessible  and 
thorough.  The  result  will  be  a  very  large  repository  of  survey  information,  with  many 
thousands  of  Marines  responding  to  many  questions  every  year.  For  the  Retention 
Survey,  the  database  will  have  response  data  for  many  of  the  same  Marines  across  multiple 


1 


years.  Therefore,  one  of  the  results  of  the  Retention  Census  will  be  a  longitudinal  study, 
where  the  same  individuals  will  be  polled  for  their  responses  across  numerous  timeframes. 

Given  the  vast  amounts  of  data  that  will  be  collected  over  the  years,  a  wealth  of 
potential  analyses  can  be  drawn  from  the  data.  However,  there  is  a  challenge  inherent  to  a 
longitudinal  study  initiative  in  that  the  survey  instrument  itself  will  very  likely  be  refined 
many  times  during  the  lifecycle  of  the  study.  To  ensure  the  data  is  consistently 
understandable,  these  refinements  to  the  survey  instrument  must  be  assiduously  tracked. 
While  it  is  important  to  field  the  best  possible  survey  instrument  at  the  beginning  of  the 
study,  it  is  also  essential  to  be  able  to  modify  existing  questions  on  the  instrument  and  add 
new  questions  as  well  as  analyze  the  response  data  relative  to  these  survey  instrument 
modifications.  Ultimately,  the  data  collected  over  the  years  will  be  used  for  hypothesis 
testing  in  order  to  predict  the  outcome  of  policy  options.  Preliminary  analysis  of  the  data 
will  be  accomplished  using  software  for  crosstabulations  to  display  and  examine 
distributions.  As  data  is  collected  over  the  long  term,  erratic  data  for  certain  variables  may 
be  explained  by  the  questions  asked  on  the  survey  instrument  at  the  time.  [Cooper  and 
Emory]  Thus,  the  capability  to  track  changes  to  the  survey  instrument  is  an  essential 
feature  of  any  longitudinal  study. 

At  some  future  state  of  the  Exit  and  Retention  Census  initiative,  the  data  collected 
in  prior  years  may  potentially  be  rendered  unusable  because  the  changes  to  the  survey 
instrument  become  impossible  to  track.  This  thesis  provides  a  conceptual  data  schema 
that  results  in  the  capability  to  manage  changes  to  the  survey  instrument  to  avoid  this 
situation.  In  addition  to  the  data  schema,  a  system  is  implemented  which  demonstrates  the 
capabilities  for  managing  the  survey  instrument  and  analyzing  the  collected  data  for  the 
USMC  Exit  and  Retention  Censuses. 

B.  PURPOSE 

The  purpose  of  this  study  is  to  design  an  effective  database  schema  to  support  a 
longitudinal  survey  which  will  accommodate  inquiries  over  time  as  the  same  respondents 
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answer  the  survey  from  year  to  year,  and  which  will  itself  change  over  the  years.  The 
resulting  schema  can  be  used  to  support  the  administration  of  the  USMC  surveys.  In 
addition  an  interface  to  the  database  is  provided  to  enable  the  extraction  of  subsets  of  the 
database  for  analysis  in  support  of  the  manpower  decisionmaking  process.  To  implement 
the  system,  meaningful  user  interface  requirements  for  the  survey  developer  and  analyst 
are  identified  and  analyzed  in  relation  to  the  database  schema. 

To  motivate  identification  of  the  database  requirements,  an  overview  of  existing, 
Web-based  survey  software  packages  is  conducted.  This  will  illuminate  what  features  and 
functionality  are  desirable  for  our  database  system.  In  particular,  the  time  semantics,  or 
version  management,  dimension  of  this  database  is  critical  to  a  successful  implementation. 

Extensions  of  the  basic  concepts  developed  by  this  study  are  discussed  to  provide 
input  for  improving  and  maintaining  the  longitudinal  survey  system.  Ultimately,  the  goal 
of  the  system  is  to  build  a  uniform  environment  for  survey  development,  administration, 
and  analysis.  Recommendations  are  included  for  enhancing  the  system  developed  in  this 
thesis. 

C.  SCOPE  AND  METHODOLOGY 

The  scope  of  the  thesis  includes  the  following: 


1.  An  overview  of  survey  software  packages  available  with  integrated  analysis 
capabilities.  Additionally,  statistical  analysis  software  available  for  analyzing 
the  data  regardless  of  the  software  for  administration  of  the  survey  instrument 
is  reviewed. 

2.  The  development  of  a  data  model/schema  for  the  capture  of  data  from  the 
survey  and  for  the  capture  and  tracking  of  changes  to  the  surveys  and 
questions.  This  supports  the  longitudinal  aspect  of  the  survey. 

3.  Implementation  of  the  database  in  Microsoft  Access,  including  the  user 
interface  between  Access  and  an  analytical  software  package. 
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4.  Design  and  development  of  a  user  interface  in  Visual  Basic  to  enable  the 
integration  of  the  database  with  analytical  software  packages.  This  provides 
the  capability  to  obtain  certain  pre-formatted  reports  and  data  extracts. 

The  following  methodology  is  used  to  conduct  this  research: 

1 .  Conduct  a  literature  and  World  Wide  Web  search  for  information  on  analytical 
software  for  surveys.  Analyze  the  relative  capabilities  and  functionality  of  the 
programs  found. 

2.  Develop  a  conceptual  data  model  for  the  longitudinal  surveys  using  SALSA™, 
which  could  theoretically  be  applied  to  any  longitudinal  study.  Analyze  and 
determine  the  necessary  entities  and  relationships  to  facilitate  the  longitudinal 
nature  of  the  study. 

3.  Convert  the  conceptual  model  to  a  relational  database  model  and  implement 
the  model  in  Microsoft  Access. 

4.  Design  interface  forms  in  Access  as  the  user  interface  to  the  survey  instrument 
database. 

5.  Design  preformatted  standard  reports  and  data  extracts. 

6.  Develop  a  user  interface  in  Visual  Basic  to  allow  the  system  administrator  to 
manage  the  survey  instrument,  and  manipulate  and  analyze  data  through  a 
single  system  interface.  The  interface  facilitates  the  use  of  Cognos 
Powerplay™  for  viewing  the  data. 

7.  Populate  the  database  with  the  first  version  of  the  Exit  and  Retention  survey 
instruments,  and  develop  procedures  for  maintaining  the  instruments  for  future 
versions. 

8.  Implement  the  database  by  downloading  a  subset  of  respondent  information 
entered  by  Marines  via  the  World  Wide  Web.  Produce  reports  and  various 
data  extracts  using  the  data. 

9.  Document  the  process  of  design  and  development,  conclusions,  lessons 
learned,  and  recommendations  for  follow-on  study. 

10.  Prepare  a  user's  manual  for  the  managers,  and  a  procedures  guide  for  the 
project  officers  who  will  be  maintaining  the  system  throughout  its  lifetime. 
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D.  THESIS  STRUCTURE 


This  introductory  chapter  has  provided  the  background,  scope  and  methodology 
for  the  thesis.  Chapter  II  is  a  discussion  of  the  various  software  components  needed  for 
the  thesis  and  an  overview  of  commercial  software  available.  In  Chapter  III,  the  problem 
areas  of  the  thesis  are  discussed  and  requirements  of  the  system  are  specified.  Chapter  IV 
presents  the  conceptual  design  for  building  the  database,  including  the  data  models, 
database  schema,  constraints,  and  database  administration.  Chapter  V  describes  building 
the  User  Interface,  including  the  development  of  process  models,  design  and  creation  of 
menus,  screens  and  reports,  generation  of  application  code,  and  development  of  a  user's 
manual.  In  addition  to  conclusions,  recommendations  for  fixture  enhancements  are 
included  in  Chapter  VI. 
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n.  SURVEY  SOFTWARE  OVERVIEW 


The  USMC  Exit  and  Retention  Census  initiative,  with  its  web-based  survey 
instrument,  is  intended  to  leverage  contemporary  technology  to  fulfill  its  objectives.  It  is 
important  to  understand  the  basic  processes  and  components  inherent  to  a  complete 
survey  system,  and  to  find  appropriate  technology  to  support  those  processes.  Toward 
this  goal,  we  start  with  a  review  of  web-based  survey  systems,  keeping  in  mind  the 
particular  requirements  to- support  the  longitudinal  study  being  undertaken  by  the  USMC. 
This  chapter  provides  a  conceptual  overview  of  the  system  and  reviews  several  software 
packages,  documenting  their  relative  capabilities. 

A.  WEB-BASED  SURVEY  SYSTEMS 

Software  to  support  the  USMC's  web-based  surveys  requires  features  above  and 
beyond  basic  database  functionality  which  provides  permanent  response  storage 
capabilities  as  well  as  web-authoring  tools  for  the  survey  instrument.  The  first  component 
is  the  application  that  contains  the  actual  survey  questionnaire  and  facilitates  its 
deployment  to  the  web.  This  software  assists  the  survey  administrator  in  survey 
instrument  development  and  maintenance.  It  may  include  a  web-authoring  capability  to 
facilitate  placing  the  instrument  on  the  web  in  which  case  the  web-based  instrument  then 
facilitates  the  transmission  of  responses  into  a  data  file  for  permanent  storage.  Once 
response  data  is  collected,  another  software  package  (if  not  an  integrated  part  of  the 
survey  software)  facilitates  analysis  of  selected  subsets  of  the  data.  Software  for  the 
development  of  a  user  interface  between  the  database  and  the  data  analysis  program  will 
also  be  necessary  unless  the  components  are  already  integrated. 

Figure  1  shows  a  schematic  of  a  web-based  survey  system  with  the  basic  hardware 
components  and  their  interaction  with  applications,  data,  and  software  components. 
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Figure  1.  System  Schematic  of  Longitudinal  Web-Based  Survey 

The  Surveyor's  goal  is  to  have  information  about  Respondents.  The  large  number 
of  Respondents  requires  that  a  robust  mechanism  be  in  place  for  them  to  deliver  that 
information,  rather  than  a  direct  link  between  the  Surveyor  and  the  Respondents. 
Therefore  the  survey  instrument  is  delivered  to  the  Respondents  as  an  HTML  survey  from 
a  web  server.  Respondents  then  enter  data  which  the  web  server  collects  and  sends  to  the 
Permanent  Database.  The  Respondents  only  interact  with  the  web  server  in  their  role  of 
providing  the  data  to  the  system. 

The  Surveyor's  role  as  depicted  in  Figure  1  is  clearly  more  involved  than  the 
Respondent.  The  Surveyor  must  develop  and  deploy  the  Survey  instrument  on  the  Web 
Server.  Prior  to  placing  it  on  the  web,  it  must  be  designed,  documented  and  stored  for 
future  reference  using  the  Survey  Application.  Figure  1  shows  the  Surveyor  employing  a 
User  Interface  to  place  information  about  surveys  in  the  Survey  Application.  The  survey 
instrument  is  then  permanently  maintained  in  the  Survey  Application.  The  Surveyor  also 
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sends  requests  via  the  user  interface  to  the  Analysis  Software  for  analysis  of  response  data 
and  to  the  Survey  Application  for  the  survey  instruments  and  related  reports.  When  the 
Surveyor  sends  request  to  the  Analysis  Software,  the  response  data  is  passed  from  the 
Permanent  Database  to  the  Analysis  Software  either  directly  or  via  the  User  Interface. 

Given  this  general  overview  of  the  system  components,  the  software  required  to 
support  the  USMC  Surveys  must  include: 

1.  Survey  software  to  develop  Survey  Instruments  and  maintain  them  in  a 
database  for  the  lifecycle  of  the  USMC  Surveys; 

2.  Analysis  software  to  provide  analytical  capabilities  for  research  on  response 
data  collected; 

3.  Graphical  User  Interface  (GUI)  software  such  as  Visual  Basic  to  provide  an 
integrated  system  environment  for  the  user. 

The  still  growing  popularity  of  the  Internet  has  generated  a  vast  supply  of  flexible 
web-based  development  tools.  These  tools  are  evolving  rapidly,  with  a  wide  variance  in 
the  approaches  software  development  companies  are  taking  As  a  result,  there  are 
numerous  tools  of  varying  quality  that  can  be  used  for  the  development  of  an  HTML 
survey  instrument.  There  is  a  number  of  software  development  companies  with 
specialized  survey  development  packages.  Since  these  tools  are  designed  specifically  for 
survey  development,  most  of  them  have  an  internal  analysis  capability,  as  well  as  the 
ability  to  format  the  data  for  transfer  to  a  robust  statistical  analysis  tool.  A  powerful 
alternative  to  purchasing  a  specialized  survey  development  tool  is  to  use  web-authoring 
software  for  survey  creation,  and  to  choose  a  robust  statistical  analysis  package  to 
examine  the  results.  Increased  availability  of  web-authoring  software  fulfills  this  need. 
Accordingly,  various  web-authoring  tools  for  surveys  and  their  associated  capabilities  and 
limitations  are  examined  in  the  next  section.  In  the  subsequent  section,  statistical  analysis 
software  capable  of  providing  a  broad  range  of  statistics  on  complex  data  subsets  is 
examined.  A  survey  of  these  two  components  of  the  survey  system  will  give  the 
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contemporary  surveyor  a  good  sense  of  the  current  state  of  software  for  collecting  and 
understanding  large  volumes  of  data. 

Software  to  support  the  other  component  of  the  longitudinal  survey  system,  the 
GUI  interface,  is  more  widely  understood  and  will  not  be  reviewed  here.  The  software  for 
developing  the  GUI  interface  component  should  be  a  flexible  programming  language  such 
as  Visual  Basic. 

B.  SURVEY  SOFTWARE. 

There  are  numerous  quality  development  tools  for  the  creation  of  web-based 
surveys.  Many  come  with  their  own  data  administration  modules,  as  well  as  analysis 
packages.  For  the  USMC  Retention  and  Exit  Survey,  as  with  most  web-based  surveys, 
the  survey  software  chosen  requires  certain  capabilities.  It  must: 

1 .  allow  lengthy  surveys  (of  at  least  280  questions); 

2.  allow  many  respondents; 

3 .  allow  branching  in  the  survey  so  that  respondents  need  only  respond  to 
appropriate  questions; 

4.  automatically  populate  the  database; 

5.  provide  security  of  respondent’s  private  information; 

6.  provide  entry  validation; 

7 .  provide  a  user  friendly  interface  for  administrators  and  the  respondents; 

8.  allow  a  wide  range  of  item  and  response  types. 

Because  this  is  a  longitudinal  survey  system,  the  responses  will  be  stored  in  a 
permanent  database  external  to  the  web  survey  package,  so  there  is  no  requirement  for 
this  component  to  have  an  analysis  or  data  management  capability.  However,  these 
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capabilities  are  imperative  for  the  system  as  a  whole,  so  the  analytical  and  data 
management  components,  if  any,  of  packages  will  be  considered. 

This  examination  of  web  survey  development  packages  concentrates  on  those 
showing  promise  to  support  extensive,  long-term  surveys.  There  are  numerous  packages 
available  which  are  designed  to  support  web  surveys  on  a  smaller  scale  and  for  one-time 
surveys,  such  as  specific  marketing  studies.  This  examination  should  not  be  considered  as 
a  comprehensive  list,  but  an  evaluation  of  only  a  few  of  the  means  of  getting  a  survey 
instrument  on  the  web. 

The  survey  development  tools  in  Table  1  can  be  used  for  implementing  a  survey  on 
the  web.  Most  include  analysis  capabilities  in  addition  to  merely  deploying  a  survey 
instrument.  Although  not  a  tailored  survey  software  application,  Lotus  Domino  is 
included  as  a  development  tool  that  can  be  used  to  design  a  proprietary  survey  application. 


Capabilities 

Cost 

Does 

Large 

Surveys 

Longitudina 

1  Studies 

Works 

With 

Other 

Software 

Entry 

Validation 

. 

Analysis 

Capability 

■ 

Products 

Survey  Select 

Saja  Software, 

Inc. 

$595  to 
$1285 

Yes 

No 

Yes 

Yes 

Limited 

Yes 

SurveySolutions 

Perseus 

Development 

Corp. 

$179 

No 

Yes 

Yes 

Limited 

statistics 

Unknown 

Domino 

Lotus 

Development 

Corp. 

$495 

Yes 

N/A 

Yes 

Yes 

N/A 

Yes 

Knquisite 

Catapult  Systems 
Corp- 

Call  for 
price 

Yes 

No 

Yes 

Yes 

Limited 

Unknown 

Surveys  with 
Confidence 

SPSS,  Inc. 

$999 

Yes 

No 

Yes 

Yes 

Complete 

Unknown 

SurveyTracker 

National 

Computer 

Systems,  Inc. 

Call  for 
price 

No 

unknown 

Yes 

Complete 

Unknown 

Table  1 .  Summary  of  Survey  Software  Packages/Options  Reviewed 
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In  order  to  support  large  surveys,  an  application  must  support  branching,  large 
numbers  of  respondents,  and  many  questions.  To  support  longitudinal  surveys,  a  package 
must  also  have  the  capability  to  manage  versions  of  surveys  and  questions. 

The  survey  software  should  allow  importing  and  exporting  in  commonly  used 
formats  to  be  compatible  with  other  applications  that  might  be  used  in  conjunction  with  it. 
For  instance  the  survey  instruments  might  be  desired  for  publication  to  the  web  in  HTML 
or  a  report  might  be  desired  from  it  for  downloading  in  a  particular  desktop  administrative 
tool.  Additionally,  the  data  collected  should  easily  be  made  available  for  analysis  in  a 
program  of  the  user's  choice.  Some  survey  software  comes  with  built-in  analysis  tools,  but 
the  capabilities  are  usually  limited. 

For  Entry  Validation,  the  software  should  provide  a  way  to  define  validation  rules 
when  respondents  provide  answers.  This  capability  includes  the  support  for  multiple  data 
types,  and  helps  ensure  that  the  data  being  received  is  indeed  the  data  desired  for  analysis. 
Entry  validation  also  provides  data  integrity,  since  data  of  undesired  format  is  prevented 
from  polluting  the  database. 

Security  provides  control  over  data  access,  another  aspect  of  data  integrity.  A 
good  survey  software  package  should  provide  some  level  of  security  for  the  database,  as 
well  as  the  response  data.  It  should  also  ensure  that  any  private  information  of 
respondents  is  protected.  From  the  perspective  of  respondents,  a  security  feature  that 
maintains  their  anonymity  also  encourages  them  to  provide  candid  responses.  From  a 
database  administration  perspective,  the  feature  is  necessary  to  protect  confidential 
information. 

Some  survey  software  packages  have  variable  price  ranges,  depending  on  the 
desired  functionality.  Additional  modules  may  be  needed  to  give  the  survey  software  a 
web-based,  e-mail  or  network  capability. 

No  survey  software  reviewed  mentioned  the  administration  of  longitudinal  surveys. 
Those  that  have  the  complete  analysis  capabilities  could  certainly  handle  the  analysis  of 
longitudinal  data,  but  the  problem  of  tracking  a  survey  instrument  over  time  is  not 
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explicitly  considered  by  any  of  them.  The  impetus  for  these  commercially  available  survey 
tools  is  largely  marketing  and  customer  satisfaction  surveys.  Longitudinal  studies  require 
a  long-term  commitment  and  dedicated  administrative  overhead  to  manage  the  overall 
process.  The  lack  of  a  short-term  payoff  makes  this  type  of  study  unattractive  to  the 
business  world,  which  constitutes  most  of  the  market  for  the  software  vendors. 

Longitudinal  studies  are  more  in  the  realm  of  government,  research  and  academic 
organizations.  As  such,  they  are  centralized  and  serve  the  broad  purposes  of  a  large 
community  with  long  term  goals.  Software  applications  designed  to  support  such  an 
effort  would  be  proprietary  by  nature.  This  observation  gives  insight  into  the  apparent 
lack  of  support  for  longitudinal  surveys  in  conjunction  with  commercially  available  survey 
software. 

The  USMC  Survey  Instrument  was  designed  for  the  web  using  Lotus 
Development  Corporation's  Domino  software.  The  first  iterations  of  both  the  Exit  and 
Retention  Censuses  were  designed  and  implemented  without  a  database  schema  to  support 
tracking  multiple  survey  instruments  over  time.  This  thesis  provides  a  design  and 
implementation  of  a  Microsoft  Access  relational  database  to  manage  a  longitudinal  survey. 
Because  the  Survey  Instrument  has  already  been  built  and  placed  on  the  Internet,  the 
requirement  for  this  study  is  to  store  the  details  of  the  Survey  Instrument  in  an  appropriate 
database  application.  The  main  goal  of  the  system  is  to  provide  survey  instrument 
lifecycle  management  for  both  longitudinal  and  static  surveys.  Links  to  analytical 
capabilities  will  be  provided  in  two  ways:  a  text  file  can  be  generated  which  can 
subsequently  be  imported  into  statistical  analysis  software  packages  such  as  SAS™  or 
SPSS™,  and  a  direct  connection  will  be  provided  to  the  Cognos  Powerplay™  tool  which 
can  do  multidimensional  crosstabs  displays  and  reports. 

Now  that  we  understand  the  components  that  should  be  in  a  generic,  longitudinal 
survey  system,  we  can  apply  this  insight  to  the  USMC  Surveys  to  generate  specific 
requirements  as  discussed  in  the  next  chapter. 
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m.  PROBLEM  BACKGROUND  AND  REQUIREMENTS  SPECIFICATION 

The  Marine  Corps  Exit  and  Retention  Censuses  are  the  impetus  for  the 
development  of  a  data  model  and  schema  that  reflects  their  particular  requirements.  The 
Marine  Corps'  initiative  is  to  conduct  two  surveys  primarily  for  the  purpose  of  statistical 
analysis.  All  Marines  who  are  exiting  active  duty  will  be  required  to  take  the  Exit  survey. 
On  an  annual  basis,  all  Marines  will  be  required  to  take  the  Retention  survey.  An  overall 
objective  is  to  capture  data  about  four  classes  of  people:  those  who  say  they  are  leaving 
and  leave;  those  who  say  they  are  leaving  and  stay;  those  who  say  they  are  staying  and 
stay;  and  those  who  say  they  are  staying  and  leave.  General  officers,  officer  candidates, 
and  recruits  will  not  be  required  to  take  the  surveys.  [CMC,  1999]  While  there  are 
questions  asked  on  the  Exit  survey  that  are  only  appropriate  for  a  Marine  who  is  leaving 
the  service,  and  questions  on  the  Retention  that  are  only  asked  of  Marines  staying  in,  there 
are  also  many  questions  common  to  both  surveys.  It  is  necessary  to  analyze  the  data 
elements  of  these  surveys  that  will  be  captured  in  the  database  in  order  to  understand  these 
requirements.  For  clarity  and  brevity,  we  adopt  the  unofficial  acronym  MCERC  (Marine 
Corps  Exit  and  Retention  Censuses)  for  the  system  being  developed  to  support  the  USMC 
surveys  in  this  thesis. 

A.  USMC  SURVEY  REQUIREMENTS 

The  survey  instrument  provides  the  necessary  information  to  gain  a  basic 
understanding  of  the  survey  system  requirements.  By  studying  the  questions  and  response 
alternatives,  the  type  of  data  that  will  be  held  in  the  database  can  be  determined.  The  data 
collected  as  well  as  the  questions  themselves  must  be  kept  in  the  database  in  a  logical 
schema  so  the  data  can  be  related  back  to  the  questions  asked.  Information  about  the 
survey  instruments  and  each  question  on  them  should  be  maintained  for  the  survey 
management  aspect  of  the  system.  This  information  is  typically  referred  to  as  a  codebook 
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for  the  survey.  Another  aspect  is  that  of  data  analysis,  for  which  response  information 
must  be  kept,  including  data  about  the  responses  and  the  respondents  themselves. 

A  representative  sample  of  questions  from  the  Exit  and  Retention  surveys  is  given 
in  Figure  2.  Both  surveys  are  lengthy,  with  a  broad  spectrum  of  questions.  The  Exit 
survey  has  over  150  questions,  and  the  Retention  survey  has  over  250  questions.  Many 
questions  are  repeated  between  the  two  surveys.  The  questions  from  the  Retention  survey 
can  be  found  in  Appendix  A. 


Spoucareer 

To  what  extent  have  your  spouse's  career  opportunities  been  limited  by  frequency  of  relocation? 

1. 

Not  at  all 

2. 

Somewhat 

3. 

A  great  deal 

spouloca 

To  what  extent  have  your  spouse's  career  opportunities  been  limited  by  frequency  of  relocation? 

1. 

Not  at  all 

2. 

Somewhat 

3. 

A  great  deal 

daycare  How  satisfied  are  yu  with  the  availability  of  daycare  in  your  area? 

.4. 

Very  satisfied 

3. 

Somewhat  satisfied 

2. 

Somewhat  dissatisfied 

1. 

Very  dissatisfied 

0. 

n/a 

marital  What  is  your  current  marital  status? 

1. 

Single  and  never  married 

2. 

Single  and  divorced 

3. 

Legally  separated 

4. 

Married  (first  marriage) 

5. 

Married  (previously  divorced  or  widowed) 

6. 

Widowed 

milhousing 

Do  you  live  in  military  housing? 

i. 

Yes 

2. 

No 

trainready 

I  have  received  the  training  needed  to  make  my  contribution  to  unit  readiness. 

4. 

Strongly  agree 

3. 

Somewhat  agree 

2. 

Somewhat  disagree 

1. 

Strongly  disagree 

Figure  2.  Questions  and  Choice  Alternatives  for  USMC  Surveys 
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Although  there  are  various  formats  for  survey  questions,  the  concept  is 
straightforward.  A  survey  question  is  presented  and  a  respondent  provides  a  response  to 
it.  MCERC  must  be  flexible  enough  to  accommodate  different  formats  for  responses. 
Since  there  will  be  different  types  of  data  based  on  the  responses,  it  must  also  be  rigid 
enough  to  maintain  integrity  of  responses  in  spite  of  the  variance  in  their  formats. 

The  requirements  for  the  basic  survey  system  can  be  divided  into  two  main 
categories:  providing  a  relational  database  structure,  and  making  the  data  available  for 
analysis  and  reports. 

Because  the  USMC  intends  this  to  be  a  longitudinal  study,  the  factor  of  time  must 
be  accommodated  in  the  schema.  Where  many  surveys  are  conducted  only  to  gather  a 
one-time  data  sample,  the  USMC  surveys  will  presumably  be  conducted  over  many  years. 
The  Exit  survey  will  be  a  requirement  for  every  Marine  to  take  before  leaving  active  duty 
service.  With  the  Retention  survey,  the  same  respondents  may  be  responding  multiple 
times,  and  the  intention  is  that  there  be  mandatory  annual  participation.  Thus  the 
Retention  survey  is  truly  longitudinal  in  that  the  same  respondents  will  be  providing, 
responses  to  the  same  questions  as  well  as  new  and  revised  questions  over  time. 
Therefore,  there  is  a  requirement  to  structure  the  data  in  a  manner  that  captures  this 
longitudinal  aspect. 

The  intention  to  field  the  surveys  for  many  years  dictates  that  inevitable  changes  to 
the  survey  instrument  must  also  be  accommodated.  The  high  likelihood  that  questions  will 
be  added,  subtracted,  or  modified  creates  the  need  to  track  these  types  of  changes  as  they 
occur  over  the  lifetime  of  the  survey  system.  Analysts  of  the  data  need  to  know  when 
their  time-series  data  is  based  on  more  than  one  version  of  a  question. 

Requirements  to  provide  survey  management  as  well  as  data  analysis  have  been 
identified.  These,  combined  with  the  requirement  to  accommodate  them  within  a  single 
system,  drive  the  design  of  a  user  interface.  This  interface  should  allow  the  user  to  easily 
enter  questions  into  the  MCERC  database  and  associate  them  with  appropriate  survey 
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versions.  It  should  allow  for  modification  of  existing  questions,  and  addition  of  questions 
without  compromising  the  data  collected  prior  to  the  change.  The  interface  will  also  allow 
users  to  generate  output  files  that  can  be  accessed  by  statistical  analysis  software  which 
can  manipulate  and  analyze  the  responses. 

B.  ANALYSIS  REQUIREMENTS 

There  are  many  possibilities  for  analysis  of  the  data  that  will  result  from  these 
surveys.  Of  primary  interest  is  how  variance  in  responses  fluctuates  among  different 
demographic  factors.  For  instance,  there  may  be  interest  in  how  responses  to  questions 
relating  to  leadership  style  vary  by  Military  Occupation  Specialty  (MOS).  Responses  to 
certain  questions  by  female  Marines  may  be  compared  to  the  responses  of  males.  Certain 
communities  within  the  Marine  Corps  reflect  a  high  investment  and  are  difficult  to  retain. 
Any  analysis  that  may  give  insight  into  these  communities  may  help  shape  policy  to  retain 
their  critical  skills.  As  an  example,  the  aviation  community  may  respond  quite  differently 
to  questions  about  military  benefits  than  other  communities.  These  kinds  of  analyses  can 
potentially  provide  the  type  of  insight  decision-makers  need  to  craft  policy.  For  MCERC, 
the  data  analysis  capability  must  give  views  of  the  data  that  show  the  relative  numbers  of 
responses  against  desired  variables. 

For  the  USMC  Surveys,  the  reporting  and  analytical  software  in  use  by  the  survey 
sponsor,  Manpower  and  Reserve  Affairs  (M&RA),  Headquarters,  U.  S.  Marine  Corps 
(HQMC),  is  PowerPlay™  by  Cognos,  Inc.  Powerplay™  provides  the  user  with 
crosstabulations  capability.  It  comes  with  a  component,  Transformer™,  which  allows 
data  modeling  for  multidimensional  analysis.  Powerplay™  is  a  leading  Online  Analytical 
Processing  (OLAP)  tool  with  extensive  drill-down,  slice  and  dice  capability.  MCERC 
must  provide  a  way  via  the  user  interface  for  the  analysts  to  access  the  capabilities  of 
PowerPlay™. 

A  summary  of  requirements  for  the  MCERC  system  requirements  is  given  in 
Table  2. 
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Summary  of  Requirements 

Category 

Requirement 

Survey  Management 

Database  schema  for  management  of  Surveys  and  Questions 

Must  accommodate  changes  in  survey  instrument  (questions  and  surveys) 

Data  Analysis 

Response  data  must  be  related  to  Surveys  and  Questions  in  the  schema. 

Data  schema  must  support  longitudinal  analysis  of  responses 

Interface  must  integrate  survey  database  and  PowerPlay™  analysis  software 

Must  be  able  to  generate  Survey  Codebooks 

Table  2.  Summary  of  Requirements  for  MCERC  to  Support  the  USMC  Surveys 

With  these  requirements  specified,  the  data  model  for  MCERC  can  be  developed 
and  implemented,  then  integrated  with  the  analysis  software  via  a  user  interface  to  provide 
all  required  capabilities  of  the  system. 
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IV.  BUILDING  THE  DATABASE 


One  of  the  key  milestones  for  the  implementation  of  the  longitudinal  survey  system 
is  the  development  of  an  appropriate  data  model  and  corresponding  database  schema.  The 
model  must  correctly  portray  the  various  entities  that  exist  in  the  survey  application  as 
well  as  the  relationships  between  them.  Similarly,  the  database  schema  must  implement 
these  entities  and  relationships  in  a  physical  database  that  serves  as  the  engine  of  the 
overall  system.  Data  models  and  a  database  schema  for  MCERC  are  developed  with 
system  requirements  in  mind  as  the  basis  for  deeper  analysis. 

A.  DEVELOPING  THE  CONCEPTUAL  DATA  MODEL 

A  successful  database  implementation  should  be  preceded  by  the  development  of 
thoroughly  analyzed  data  models.  To  obtain  an  appropriate  data  model  for  a  system,  the 
methodology  used  should  take  the  requirements  of  the  system  as  the  basis  for  developing 
and  documenting  the  model.  Two  methodologies  for  accomplishing  this  are  the  Entity- 
Relationship  (E-R)  Model  and  the  Semantic  Object  Model  (SOM).  The  E-R  approach 
identifies  each  entity  and  all  of  its  associated  relationships  with  other  entities.  The  SOM 
approach  also  identifies  entities  (called  semantic  objects)  as  well  as  their  attributes, 
although,  unlike  the  E-R  approach,  SOM  represents  relationships  between  objects  in  a  less 
explicit  manner.  Objects  axe  embedded  within  other  objects  to  reflect  a  relationship. 
SOM  also  gives  all  the  attributes  and  associates  them  directly  with  the  objects.  The  nature 
of  the  relationships  between  objects  and  with  attributes  can  also  be  described  in  SOM  by 
showing  cardinalities.  The  SOM  approach  is  used  in  this  thesis  to  derive  a  data  model  for 
MCERC. 

I.  Primary  Objects 

The  first  issue  is  to  determine  what  the  actual  objects  should  be  in  the  survey 
system.  David  M.  Kroenke  defines  an  object  as  “a  named  collection  of  attributes  that 
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sufficiently  describes  a  distinct  entity.”  [Kroenke,  1995]  Based  on  an  analysis  of  the 
system  requirements,  the  following  objects  have  been  identified  as  integral  to  the  system: 
Surveys,  Questions,  Respondents,  and  Responses. 

The  Semantic  Objects  relating  to  these  four  objects  are  presented  in  Figure  3.  As 
can  be  seen,  a  semantic  object  has  its  attributes  associated  directly  with  it  by  simply  fisting 
them  within  the  object.  Key  attributes  (identifying  attributes)  are  designated  with  asterisks 
in  the  figure,  using  two  asterisks  for  unique  keys  and  one  for  non-unique  keys.  To 
establish  a  relationship  between  objects,  the  objects  are  embedded  in  each  other.  This 
serves  to  directly  relate  the  key  attributes.  Cardinalities  can  be  shown  for  each  attribute, 
meaning  the  minimum  and  maximum  occurrences  of  the  attribute  as  it  relates  to  a  single 
instance  of  the  object.  The  cardinalities  are  designated  to  the  right  of  each  attribute  by  the 
two  values  separated  by  a  hyphen.  The  minimum  cardinality  is  the  left  value,  the 
maximum  the  right. 
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Figure  3 .  Primary  Objects  of  MCER  C  Model 

Figure  3  depicts  a  Semantic  Object  Model  with  only  the  four  objects  of  a  simple 
survey  system  that  allows  for  management  of  multiple  surveys  and  respondents.  These 
primary  objects,  while  modeling  the  basic  ideas  of  a  simple  survey  system,  are  insufficient 
to  handle  all  the  problems  associated  with  the  USMC  Census  database.  Other  objects 
must  be  added  to  the  model  to  handle  issues  surrounding  the  management  of  a  large. 
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longitudinal  survey.  These  additional  objects  will  be  described  below.  The  following  is  a 
description  of  the  basic  objects,  their  associated  relationships,  and  their  key  attributes. 

The  SURVEY  object  models  the  survey  instrument.  The  SurveyName  field  is  the 
uniquely  identifying  key  for  a  SURVEY,  and  will  be  either  the  Exit  survey  or  Retention 
survey  for  the  USMC  Census  database.  A  SURVEY  consists  of  many  QUESTIONS,  and 
many  RESPONDENTS  can  take  a  particular  SURVEY.  This  is  not  modeled  directly, 
however,  rather  the  RESPONSE  object  is  used  to  capture  the  relationship  between 
RESPONDENT  and  SURVEY.  While  one  SURVEY  can  have  many  QUESTIONS,  the 
business  rules  pertaining  to  survey  questions  will  determine  whether  QUESTIONS  can 
pertain  to  one  or  many  SURVEYS.  In  order  to  reuse  QUESTIONS,  they  must  be 
associated  with  many  SURVEYS  in  this  model. 

QUESTION  is  a  separate  object  from  SURVEY  because  questions  can  take  many 
forms,  and  each  survey  can  take  many  forms  with  varying  numbers  and  types  of  questions. 
This  relationship  is  necessary  to  provide  the  flexibility  to  manage  multiple  surveys.  If 
questions  were  only  a  field  within  a  survey,  then  each  question  developed  could  only  be 
used  for  one  survey.  With  the  separation  of  the  objects,  questions  can  be  reused.  The 
VariableName  field  uniquely  identifies  a  QUESTION  and  is  therefore  the  key  for  this 
primary  object. 

RESPONDENT  is  a  separate  object  that  captures  the  notion  there  will  be 
individuals  taking  the  survey  and  providing  responses  which  we  want  to  measure  in  this 
application.  For  the  purposes  of  this  database,  certain  attributes  of  respondent  information 
require  protection  under  the  Privacy  Act  of  1974;  treating  RESPONDENT  as  a  separate 
object  facilitates  the  protection  of  this  stored  data.  Certain  demographic  and  personal 
information  obtained  for  this  object  in  the  MCERC  database  is  extracted  from  the  USMC 
master  file  rather  than  entered  directly  by  the  respondent.  The  primary  key  of  the 
RESPONDENT  object  is  the  SSN  field  (Social  Security  Number),  with  the  Name  of  the 
respondent  being  a  secondary  identifier.  Only  the  last  four  digits  of  the  SSN  are  used  to 
establish  relationships  with  other  entities. 
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RESPONSE  is  a  separate  object,  and  represents  the  key  data  elements  of  interest 
for  analysis  in  this  database.  Determining  the  best  way  to  handle  this  object  depends  on 
the  choice  of  business  rules  for  this  system.  One  approach,  in  which  questions  for  each 
version  of  SURVEY  are  viewed  as  relating  only  to  that  particular  survey,  is  to  treat  each 
response  as  one  RESPONSE  object  for  each  RESPONDENT  for  each  SURVEY.  This 
would  appear  as  a  sequential  list  of  answers.  Another  view,  which  is  adopted  here,  allows 
each  particular  QUESTION  to  be  used  on  many  surveys,  in  varying  sequence,  and  in 
various  versions.  In  this  case,  the  RESPONSE  object  appears  one  time  for  each 
QUESTION  for  each  RESPONDENT  for  each  SURVEY  answered.  This  requires 
significantly  more  computing  and  storage  overhead  as  a  tradeoff  against  more  usability 
and  flexibility  in  the  system.  Each  RESPONSE  is  uniquely  identified  by  a  combination  of 
the  key  fields  of  SURVEY,  QUESTION,  and  RESPONDENT.  The  key  for  RESPONSE 
is  therefore  a  combination  of  the  keys  of  these  three  objects. 


Figure  4.  Entity-Relationship  Schematic  of  Simple  Survey  System 


The  next  step  we  take  is  to  convert  the  basic  semantic  object  model  shown  in 
Figure  3  into  a  database  schema,  in  this  case  a  Microsoft  Access  database.  This  gives  an 
explicit  representation  of  the  relationships  between  the  entities  that  result  from  the  SOM. 
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Figure  4  shows  the  resulting  tables  and  relationships  between  the  tables.  In  this  model,  the 
SURVEY  table  has  a  one-to-many  relationship  with  RESPONSE,  meaning  a  single 
SURVEY  can  have  many  RESPONSES  and  a  single  RESPONSE  pertains  to  one  and  only 
one  SURVEY. 

SURVEY  is  also  joined  via  a  junction  table  to  QUESTION,  reflecting  a  many-to- 
many  relationship.  A  single  SURVEY  will  have  at  least  one,  but  may  have  many 
QUESTIONS.  Likewise,  a  single  QUESTION  will  pertain  to  at  least  one,  but  may  be 
asked  on  many  SURVEYS. 

Another  many-to-many  relationship  exists  between  SURVEY  and 
RESPONDENT,  with  RESPONSE  serving  as  a  junction  table  in  this  case.  In  the  model, 
we  could  have  created  a  direct  relationship  between  RESPONDENT  and  SURVEY,  but 
this  would  have  been  redundant,  since  the  relationship  is  already  captured  via  the 
RESPONSE  table.  A  single  SURVEY  can  have  many  RESPONDENTS,  and  a  single 
RESPONDENT  can  respond  to  many  different  SURVEYS. 

The  QUESTION  table  has  a  similar  redundant  relationship  at  first  glance.  The 
many-to-many  relationship  between  QUESTION  and  SURVEY  has  already  been 
discussed  The  RESPONSE  table  also  relates  these  two  objects  in  a  many-to-many 
relationship.  However,  for  a  RESPONSE  to  exist,  there  also  has  to  be  a  RESPONDENT. 
QUESTIONS  and  SURVEYS  will  exist  before  there  are  any  RESPONDENTS.  The 
redundancy  here  is  necessary  to  manage  surveys  and  questions  prior  to  having  any 
responses  by  respondents.  The  survey  designer  must  create  a  SURVEY  and  associated 
QUESTIONS  first  in  order  to  later  obtain  RESPONSE  and  RESPONDENT  information. 

A  single  instance  of  a  QUESTION  can  have  from  zero-to-many  RESPONDENTS. 
Likewise  a  single  RESPONDENT  will  answer  one-to-many  QUESTIONS.  This  creates  a 
many-to-many  relationship  between  QUESTION  and  RESPONDENT,  which  are  joined 
via  the  RESPONSE  table.  A  single  instance  of  QUESTION  can  have  many  RESPONSES, 
but  a  single  RESPONSE  pertains  to  one  and  only  one  QUESTION.  A  RESPONSE  is 
defined  as  one  respondent’s  answer  to  one  QUESTION  of  one  SURVEY.  Although 
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RESPONSE  serves  as  a  junction  table  for  the  above-mentioned  many-to-many 
relationships,  a  single  instance  of  RESPONSE  can  pertain  to  one  and  only  one 
QUESTION,  SURVEY,  and  RESPONDENT.  Therefore  each  RESPONSE  is  uniquely 
identified  by  the  combination  of  the  keys  of  the  other  three  objects.  The  RESPONSE 
object  represents  the  ultimate  target  of  the  survey  system,  which  is  to  gather  many  unique 
responses  for  analysis. 

2.  Refinement  of  the  Data  Model  for  Longitudinal  Surveys 

The  foregoing  SOM  and  resulting  diagram  of  its  resultant  relationships  provide  the 
basis  for  a  simple  survey  system,  yet  will  not  suffice  for  a  large,  longitudinal  survey  system 
like  the  USMC  Longitudinal  Censuses  for  Exit  and  Retention  (MCERC).  There  are 
complex  issues  which  complicate  the  implementation  of  the  system,  and  which  require 
decisions  about  how  to  manage  the  complexity.  Additional  objects  will  have  to  be  added 
to  the  model,  requiring  more  tables  in  the  database,  and  further  analysis  of  the 
relationships. 

There  are  at  least  three  complicating  issues  caused  by  the  size  and  the  longitudinal 
nature  of  the  system.  First  among  them  is  version  management  due  to  the  longitudinal 
nature  of  the  survey  and  the  necessity  to  facilitate  change.  Secondly,  conditional 
branching  results  from  the  requirement  that  various  subsets  of  the  targeted  respondents 
need  answer  only  those  questions  pertinent  to  their  demographics,  or  questions  that  are 
only  applicable  contingent  upon  answers  to  previous  questions.  Related  to  this  is  the  third 
issue  of  sequencing  the  questions  between  different  versions  of  surveys  and  the  different 
subsets  of  respondents  who  will  see  them 

The  longitudinal  nature  of  MCERC  creates  the  requirement  for  version 
management.  Changes  to  surveys  that  span  many  years  are  inevitable.  Responses  to 
certain  questions  are  very  likely  to  prove  too  erratic  for  insightful  analysis,  and  such 
questions  will  be  refined,  rewritten,  or  even  eliminated.  This  entails  management  of 
various  versions  of  what  is  essentially  the  same  question,  and  management  of  a  new 
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version  of  the  actual  survey  every  time  a  change  is  made  to  the  survey  in  any  meaningful 
way.  Even  without  any  changes  in  the  actual  survey  involving  its  appearance,  wording, 
sequence,  etc.,  over  the  years  of  implementation,  it  may  still  be  desirable  to  have  each  time 
period  represent  a  different  version  of  the  survey.  For  instance,  the  USMC  Retention 
census  will  be  taken  annually  by  most  Marines  between  May  and  September.  Each  year 
could  be  considered  a  different  version  for  ease  of  management,  although  the  dating  of 
survey  responses  renders  this  unnecessary. 

Conditional  branching  occurs  in  MCERC  based  either  on  demographics  of 
respondents,  or  their  responses  to  conditional  questions.  For  example,  some  questions  are 
to  be  answered  by  officers  only,  and  some  by  enlisted  only.  If  the  information  on  the 
respondent  indicates  he  or  she  is  an  officer,  then  the  enlisted  only  questions  will  not  be 
presented  to  him  or  her.  This  is  an  example  of  conditional  branching  based  on 
demographics.  A  question  about  family  housing  support  will  not  be  asked  a  Marine  who 
first  answers  that  she  fives  in  the  bachelor  barracks.  This  is  an  example  of  conditional 
branching  based  on  a  previous  response. 

The  problem  of  sequencing  questions  in  a  complex  and  changing  survey  system 
like  MCERC  is  a  result  of  changing  sequence  as  new  versions  are  fielded,  and  maintaining 
a  desired  sequence  between  respondent  subsets  related  to  branching.  A  good  survey 
system  should  keep  questions  in  the  same  sequence  to  manage  variance  in  responses.  This 
simplifies  the  problem  a  great  deal,  since  all  demographic  groups  within  the  overall 
respondent  population  are  answering  essentially  the  same  survey.  If  the  general  sequence 
is  changed  for  a  subset  of  respondents,  this  essentially  creates  a  different  survey. 

3.  Business  Rules 

Given  the  simple  survey  system  described  previously  and  the  complicating  issues 
discussed  above,  a  set  of  business  rules  needs  to  be  defined  for  MCERC.  Once  the 
business  rules  are  initially  identified,  the  data  model  and  relational  database  schema  can  be 
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revisited  for  solutions  to  the  problems.  Table  3  displays  the  relevant  business  rules  for 
MCERC. 


1. 

A  RESPONDENT  can  take  multiple  SURVEYS,  including  both  Retention  and  Exit  surveys. 

2. 

A  RESPONDENT  answers  any  given  version  of  a  SURVEY  one  time  only. 

3. 

When  a  RESPONDrsm  taxes  a  SURVEY,  he  or  she  only  answers  QUESTIONS  related  to  that 
particular  SURVEY. 

4. 

A  QUESTION  can  appear  on  multiple  SURVEYS. 

5. 

A  QUESTION  can  be  modified,  but  only  one  version  of  it  will  appear  on  one  version  of  a 
SURVEY. 

6. 

Once  a  QUESTION  is  modified  and  placed  on  a  SURVEY,  there  is  a  different  SURVEY  version  as 
well  as  a  different  QUESTION  version. 

7. 

Every  QUESTION  m  the  database  must  be  associated  with  a  SURVEY.  (No  excess,  unused 
questions  will  be  kept  in  the  system). 

8. 

Merely  changing  the  sequence  of  a  QUESTION  without  changing  the  wording  does  not  create  a 
new  QUESTION  version,  but  does  create  a  new  SURVEY  version 

9. 

QUESTIONS  may  have  varying  numbers  of  choices  and  may  come  in  a  variety  of  formats. 

10. 

RESPONDENT’S  personal,  private  information  will  be  protected  from  uncontrolled  access. 

11. 

RESPONSE  data  will  be  accessible  for  longitudinal  analysis. 

Table  3.  Business  Rules  for  MCERC 


Clearly,  if  a  Marine  is  taking  a  Retention  survey,  he  or  she  is  expected  to  be  in  the 
service  for  the  opportunity  to  take  another  survey  of  either  type.  The  expectation  that  a 
Marine  can  take  multiple  Exit  surveys  is  justified  by  the  possibility  of  “broken  time”, 
where  a  Marine  exits  the  service  and  later  returns,  eventually  to  exit  again.  There  is  also 
the  possibility  the  Exit  survey  will  be  completed,  and  circumstances  will  subsequently 
change  before  the  Marine  actually  exits.  Such  circumstances  as  a  full-scale  deployment 
for  a  combat  situation,  unexpected  promotions  or  billet  opportunities,  or  simple  changes 
of  attitude  due  to  personal  circumstances  have  the  potential  to  keep  a  Marine  in  the 
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service  after  completing  an  exit  survey.  Although  this  is  a  rare  situation,  the  capability  to 
support  it  must  be  available  in  the  survey  system. 

4.  Conceptual  Data  Model  for  Longitudinal  Survey  System 

Now  that  the  basic  model  and  relationships  have  been  described,  the  basic  model 
can  be  modified  to  accommodate  the  business  rules  complexities  of  a  longitudinal  survey 
system.  With  respect  to  version  management,  both  SURVEYS  and  QUESTIONS  are 
highly  likely  to  encounter  changes  in  a  survey  project  spanning  an  indefinite  period  of 
time,  presumably  many  years.  The  Archetype/Version  object  provides  the  solution  to 
version  management  of  SURVEYS  and  survey  QUESTIONS.  [Kroenke,  1995]  The 
archetype  object  is  represented  with  the  common  attributes  the  object  will  have,  and  the 
version  portion  has  the  changing  attributes,  such  as  a  version  number.  Thus  it  is  a 
composite  object  with  the  primary  object  having  from  one-to-many  version  objects 
associated  with  it.  Figure  5  shows  the  Semantic  Object  Model  for  MCERC  including  this 
technique. 

Also  included  in  Figure  5  is  a  new  CHOICESET  object.  The  business  rules  allow 
for  multiple  formats  for  QUESTIONS,  meaning  they  may  be  multiple  choice,  true  or  false, 
free  text  entry,  numerical  entiy,  etc.  CHOICESET  is  related  to  the  QUESTION  object 
via  the  new  QUESTIONVERS  object,  where  QUESTIONVERS  is  the  version  portion  of 
the  archetype/version  object  for  questions.  As  the  model  shows,  a  CHOICESET  can  be 
used  on  one-to-many  QUESTIONVERS  objects,  and  a  QUESTIONVERS  will  have  one 
and  only  one  CHOICESET  object  associated  with  it.  The  unique  identifier  for  the 
CHOICESET  is  the  key  attribute  ChoiceSetID.  Note  that  there  is  a  Choice  attribute  in 
the  RESPONSE  object,  yet  there  is  no  relationship  between  RESPONSE  and 
CHOICESET.  CHOICESET  is  a  part  of  the  QUESTION/QUESTIONVERS  object,  and 
only  provides  a  mechanism  for  the  Respondent  to  make  her  choice.  A  value  for  Choice  is 
independently  entered  for  each  RESPONSE.  It  could  have  just  as  easily  been  called 
“Response”,  “Answer”,  or  “Reply.” 
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Figure  5.  MCERC  Model  with  Archetype/Version  Objects 


Figure  5  further  illustrates  the  object  for  surveys  is  now  broken  into  two  objects, 
SURVEY  and  SURVEYVERS.  The  SURVEY  object  describes  only  the  basic  idea 
behind  a  survey  with  a  particular  name,  but  as  can  be  seen,  it  can  have  many 
SURVEYVERS  objects  associated  with  each  instance  of  it.  Each  SURVEYVERS  has  a 
unique  identifier  composed  of  the  identifier  of  the  archetype  object  and  a  version  number. 
The  relationships  of  SURVEYS  with  other  objects  are  now  via  the  SURVEYVERS 
object.  The  archetype  SURVEY  object  is  only  related  to  the  version  SURVEYVERS 
object. 

Similarly,  the  object  for  questions  is  also  broken  into  two  objects,  QUESTION  and 
QUESTIONVERS.  If  a  QUESTION  is  re-worded  or  otherwise  altered  without  changing 
the  essence  or  intent  of  the  question,  the  archetype/version  object  allows  it  to  retain  the 
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same  basic  identifier.  The  QUESTIONVERS  object  will  also  retain  the  basic  identifier  of 
the  QUESTION  object,  but  will  require  a  new,  unique  version  number.  Relationships 
between  questions  and  other  objects  of  the  system  are  now  via  QUESTIONVERS,  the 
version  portion  of  the  QUESTION/QUESTIONVERS  Archetype/Version  object. 


Figure  6.  Entity-Relationship  Schematic  of  Longitudinal  Survey  System 

The  entity-relationship  schematic  resulting  from  the  full  model  with 
Archetype/Version  objects  is  depicted  in  Figure  6.  As  can  be  seen,  the  SURVEY  and 
QUESTION  archetype  objects  have  a  simple  one-to-many  relationship  with  their 
respective  version  objects,  SURVEYVERS  and  QUESTIONVERS. 
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B.  RELATIONAL  DATA  MODEL 


Data  modeling  can  also  be  accomplished  for  the  system  using  the  relational  model. 
This  technique  corresponds  directly  to  the  relations  that  will  appear  in  a  relational 
database,  unlike  the  SOM,  which  models  the  objects  as  they  are  perceived  in  reality, 
separate  from  the  database. 


MCERC  Relational  Model 

SURVEY 

(SurvevName.  Description! 

SURVEYVERS 

(SurvevName  FK.  VersionNo.  VsDetail.  Manager  TD  ! 

QUESTION 

(VariableName.  Description'* 

QUESTIONVERS 

(VariableName  FK.  VersionNo.  Format.  Onestion  Odetail 

ChoiceSetID_FK,  ID_) 

SURVEYVERSQUESTIONVERSX 

(SURVEYVERS  ID  FK.  QUESTIONVERS  ID  FK.  Sequence 

Condition) 

CHOICE_SET 

(ChoiceSetnX  ChoiceSetDescription'* 

CHOICE_SET_Choice 

(ChoiceSetID  FK.  ChoiceNumber.  ChoiceDescription  TD  ! 

RESPONDENT 

(SSN,  Name,  Gender,  Birthdate,  Race) 

RESPONSE 

(SSN  FK,  SURVEYERS  ID  FK.  OUESTIONVERS  TD  FK  Datestamn. 
Choice,  ID_) 

Figure  7.  MCERC  Relational  Model 


The  relational  model  in  Figure  7  depicts  each  relation  with  the  attributes  or 
combinations  of  attributes  (keys)  which  uniquely  identify  it  underlined.  Those  relations 
having  the  "ED_"  attribute  need  it  for  indexing,  because  they  are  associated  with  another 
relation  with  a  composite  key.  The  relations  of  this  model  correspond  to  the  tables 
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represented  in  Figure  6,  which  shows  the  relationships  between  the  tables  more 
graphically. 


C.  INTER-RELATIONAL  CONSTRAINTS 

The  foregoing  models  describe  objects  or  entities  and  the  relationships  between 
them.  However,  they  do  not  illustrate  the  inter-relational  constraints.  In  one-to-many 
relationships,  a  row  in  a  "parent"  table  can  have  many  associated  "child"  rows  in  a  child 
table.  These  relationships  can  be  constrained  as  to  whether  or  not  a  parent  must  have  at 
least  one  child,  or  whether  or  not  a  child  must  be  associated  with  a  parent.  Thus  there  are 
4  classifications  of  the  inter-relational  constraints:  Mandatory  to  Mandatory,  Mandatory 
to  Optional,  Optional  to  Mandatory,  and  Optional  to  Optional.  These  inter-relational 
constraints  must  be  enforced  to  maintain  data  integrity.  Table  4  gives  these  inter- 
relational  constraints  for  the  MCERC  system. 


Parent 

Child 

Constraint 

SURVEY 

SURVEYVERS 

Mandatory  to  Mandatory 

SURVEYVERS  . 

RESPONSE 

Mandatory  to  Optional 

SURVEYVERS 

SURVEYVERS_QUESTIONVERS_X 

Mandatory  to  Mandatory 

QUESTION 

QUESTIONVERS 

Mandatory  to  Mandatory 

QUESTIONVERS 

RESPONSE 

Mandatory  to  Optional 

QUESTIONVERS 

SURVEYVERS_QUESTIONVERS_X 

Mandatory  to  Mandatory 

CHOICESET 

QUESTIONVERS 

Mandatory  to  Mandatory 

CHOICESET 

CHOICE_SET_Choice 

Mandatory  to  Mandatory 

RESPONDENT 

RESPONSE 

Mandatory  to  Mandatory 

Table  4.  Inter-Relational  Constraints  in  MCERC 

For  the  Archetype/Version  objects  composed  of  SURVEY/SURVEYVERS  and 
QUESTION/QUESTIONVERS,  there  are  Mandatory  to  Mandatory  inter-relational 
constraints.  A  version  object  must  have  an  archetype  and  in  MCERC,  there  will  be  at 
least  one  version  required  for  each  archetype;  thus  the  inter-relational  constraints  exist  to 
enforce  this. 
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Whenever  a  survey  is  created,  there  must  be  at  least  one  question  associated  with 
it.  Likewise,  whenever  a  question  is  added  to  the  database,  it  must  be  associated  with  a 
survey.  Therefore,  junction  table  SURVEYVERS_QUESTIONVERS_X  that  associates 
QUESTIONVERS  and  SURVEYVERS  has  Mandatory  to  Mandatory  inter-relational 
constraints  with  both  of  these  relations. 

Whenever  a  question  is  placed  in  the  database,  it  must  have  a  set  of  choices 

/ 

associated  with  it.  The  CHOICE_SET  relation  is  required  to  have  at  least  one  related 
QUESTIONVERS  to  avoid  having  unused  sets  of  choices  in  the  database.  The  inter- 
relational  constraint  is  again  Mandatory  to  Mandatory. 

Because  CHOICE_SETs  may  have  varying  numbers  and  types  of  choices,  the 
CHOICE  SET  Choice  relation  defines  all  the  choices  that  can  be  associated  with  a  set  of 
choices.  This  is  also  defined  as  a  Mandatory  to  Mandatory  inter-relational  constraint 

The  RESPONSE  and  RESPONDENT  relations  represent  another  aspect  of 
MCERC,  the  data  being  gathered  after  development  of  the  actual  survey  instrument  The 
inter-relational  constraint  between  these  two  relations  is  clearly  Mandatory  to  Mandatory. 
A  RESPONSE  must  have  a  RESPONDENT,  and  a  RESPONDENT  cannot  be  possibly 
defined  until  he/she  has  provided  a  RESPONSE. 

The  other  two  relations  associated  with  RESPONSE  are  SURVEYVERS  and 
QUESTIONVERS.  Because  surveys  and  questions  must  be  written  and  made  available  to 
potential  respondents  before  responses  can  be  gathered,  there  cannot  be  a  response 
initially.  However,  a  response  is  clearly  related  to  a  question,  which  is  required  to  be  on  a 
survey.  Thus,  the  inter-relational  constraint  between  SURVEYVERS  and  RESPONSE  is 
Mandatory  to  Optional.  Likewise,  the  constraint  between  QUESTIONVERS  and 
RESPONSE  is  Mandatory  to  Optional. 

The  constraints  defined  in  the  data  model  and  schema  maintain  the  appropriate 
data  integrity  of  the  underlying  survey  management  database.  At  the  same  time  the  model 
is  flexible  enough  to  accommodate  the  complex  problems  of  a  longitudinal  survey. 
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D.  MICROSOFT  ACCESS  DESIGN/DATA  DICTIONARY 


The  design  of  the  Access  database  results  from  the  relational  model  defined  in  this 
chapter.  Building  the  Access  database  first  required  the  analysis  of  entities  and 
relationships  as  discussed  previously,  and  the  creation  of  a  data  model.  The  data  model 
was  then  implemented  in  the  SALSA  for  the  Desktop  software  from  Wall  Data,  Inc.,  a 
Computer  Aided  Software  Engineering  (CASE)  tool  for  creating  database  applications, 
either  in  SALSA  database  or  other  well-known  applications  such  as  FoxPro  or  Access. 
To  create  the  application,  the  user  develops  objects  with  attributes  in  SALSA.  The  model 
simply  describes  the  data.  From  this  model,  SALSA  for  the  Desktop  will  generate  the 
basic  tables  and  relationships  of  a  database  application  for  the  user.  Once  this  was 
accomplished  for  MCERC,  the  database  application  development  required  alterations  of 
fields  in  the  tables  to  ensure  appropriate  keys,  indexes,  and  data  types  existed.  Enforcing 
some  inter-relational  constraints  required  designing  forms  to  restrict  data  entry  for  certain 
fields,  particularly  where  the  constraints  were  designated  to  prevent  unused  records  from 
existing  in  the  database. 

When  SALSA  is  used  to  generated  the  Access  database  for  MCERC,  the  unique 
identifiers  of  the  SALSA  model  are  not  translated  into  the  key  fields  of  the  Access 
database  schema.  Instead,  each  table  is  automatically  given  a  numeric  field  named  “ID.” 
Although  it  is  possible  to  use  these  as  the  key  fields,  it  is  desirable  to  designate  meaningful 
key  fields  with  an  actual  attribute  that  uniquely  identifies  the  table.  Therefore,  the  key 
attributes  designated  in  the  original  model  are  re-designated  as  the  key  fields  in  the  Access 
schema.  Further  definition  of  fields  is  required  to  ensure  proper  constraints  are  enforced 
by  Access.  In  particular,  the  key  fields  must  be  defined  as  indexes  and  specified  as  to 
whether  or  not  duplicates  are  allowed.  Data  integrity  constraints  such  as  these  must  be 
defined  for  all  fields. 

Data  integrity  constraints  must  be  identified  and  enforced  in  the  model  for 
successful  implementation.  The  data  dictionary  in  Appendix  B  is  provided  to  identify  the 
data  types  of  each  attribute  and  give  any  pertinent  constraints  on  the  database  fields.  In 


35 


addition  to  data  types,  the  length  of  each  field  must  be  defined.  In  most  cases,  the  length 
is  given  by  a  numerical  figure,  but  in  the  case  of  fields  defined  as  "Number*'  data  types,  it 
can  be  given  as  "integer,  long  integer,  byte,  single,  or  double." 

Once  all  key  fields  of  the  tables  are  defined  properly,  other  fields  are  also  reviewed 
to  ensure  the  data  types,  field  lengths,  "required"  flags,  or  other  desired  field  properties 
are  set  correctly.  For  MCERC,  the  design  view  in  which  this  is  accomplished  for  the 
"  QuestionV ersionID_V ersionNo "  field  of  the  QUESTIONVERS  table  is  shown  in  Figure 


8.  (Note  the  triangular  selector  preceding  the  Field  Name,  designating  the  active  field.) 


Figure  8.  Design  View/Table  Definition  of  Table  QUESTIONVERS  of  MCERC 

The  SALSA  model  generated  the  fields  in  the  table,  although  the  key  fields  had  to 
be  re-designated,  because  SALSA  generated  the  "ID_"  field  for  Access  as  the  key.  In  the 
SALSA  model,  the  composite  key  "QuestionVersionID"  in  the  QUESTIONVERS  object 
of  the  model  was  the  unique  identifier  of  the  object.  The  QUESTIONVERS  table  in  the 
database  schema  is  generated  with  the  two  fields  "QuestionVersionID_ 
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QuestionName_FK"  and  " Question V ersionID_VersionNo "  corresponding  to  the  two 
fields  of  the  composite  key  from  the  SALSA  model.  This  key  prevents  having  records  in 
this  table  with  the  same  combinations  of  "QuestionVersionID_QuestionName  _FK"  and 
"QuestionVersionID_VersionNo."  The  "ID_"  field  is  retained  as  a  unique  index  for  the 
table,  although  it  is  not  a  key  field.  It  is  used  to  establish  the  many-to-many  relationship 
between  the  QUESTIONVERS  and  SURVEYVERS  tables. 

Duplicate  values  of  the  "QuestionVersionID_VersionNo"  field  must  be  allowed  so 
that  all  questions  may  have  a  version  1,  version  2,  etc.  In  Figure  8,  this  field  is  selected  so 
the  "Field  Properties"  at  the  bottom  of  the  screen  apply  to  the  version  number  field  of  a 
question  in  the  QUESTIONVERS  table.  Screens  defining  all  field  properties  are  displayed 
in  Appendix  B.  Using  these  screens,  all  fields  are  given  appropriate  definitions  to 
correctly  implement  MCERC. 

One  difficulty  involves  the  "VersionNo"  fields  of  the  QUESTIONVERS  and 
SURVEYVERS  tables,  which  must  be  incremented  by  one  for  a  new  "QuestionName"  or 
"SurveyName".  Although  the  AutoNumber  data  type  increments  by  one  every  time  an 
entry  is  made  in  the  field,  it  increments  regardless  of  the  associated  name.  Therefore,  the 
AutoNumber  data  type  does  not  provide  the  solution.  To  correctly  implement  the 
requirement,  the  database  application  must  not  allow  a  user  to  enter  a  value  in  the 
"VersionNo"  field  other  than  the  next  consecutive  number  relative  to  the  selected  primary 
identifier.  For  MCERC,  this  simply  means  that  the  application  must  require  a  Version  2 
when  there  is  only  a  Version  1  of  either  the  Exit  or  Retention  survey,  or  of  a  given 
question. 

E.  POPULATING  THE  TABLES  WITH  DATA 

Once  the  database  schema  has  been  designed  as  described,  populating  it  with  data 
constitutes  the  actual  building  of  the  database.  For  MCERC,  this  entails  two  basic 
procedures;  entry  of  the  survey  instrument,  and  entry  of  response  data.  First  the  survey 
instrument  data  must  be  entered  using  Access  forms  to  input  the  surveys  and  questions, 
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associating  all  questions  with  a  survey.  The  first  such  entry  necessarily  entails  all  fields  of 
the  Access  schema  except  for  those  specific  to  the  RESPONDENT  and  RESPONSE 
tables.  This  is  due  to  the  inter-relational  constraints  defined  previously.  Therefore,  the 
first  entiy  will  have  Version  1  of  a  Survey,  with  entries  in  all  fields  of  the  SURVEY  and 
SURVEYVERS  tables.  It  will  have  Version  1  of  the  first  question  to  be  entered,  along 
with  entries  for  all  fields  of  the  QUESTION,  QUESTIONVERS,  CHOICE_SET,  and 
CHOICE_SET_Choice  tables.  This  entails  entry  of  the  first  set  of  choices,  which  must  be 
done  in  order  to  have  a  question  defined.  The  junction  table, 
SURVE YVERS_QUE S  TIONVERS_X,  representing  the  many-to-many  relationship 
between  questions  and  surveys  will  have  the  key  fields  for  the  relationship  automatically 
populated  and  entries  made  for  all  required  fields.  This  initial  data  entry  requires  a 
complicated  set  of  inter-related  forms  and  linked  forms  to  be  designed  as  part  of  the 
interface  (see  Chapter  V). 

The  primary  form  designed  to  accommodate  this  initial  data  entry  is  displayed  in 
Figure  9.  The  user  enters  the  name  of  the  first  survey,  which  is  Version  1  by  default.  A 
description  of  the  general  purpose  of  the  survey  is  then  entered,  as  is  the  name  of  the 
surveyor  or  "Manager."  Because  this  is  the  first  entry,  there  are  no  questions  displayed  in 
the  field  designed  for  the  selection  of  existing  questions.  Of  the  two  buttons  at  the  bottom 
of  the  form,  the  "Create  a  New  Question"  button  should  be  chosen.  This  button  takes  the 
user  to  a  form  to  accomplish  this  entry,  which  has  a  similar  button  to  create  a  new  set  of 
choices  to  associate  with  the  question.  The  development  of  the  User  Interface  will  be  fully 
explained  in  Chapter  V,  which  will  clarify  the  method  for  populating  the  database  with  all 
elements  of  the  survey  instruments. 

Questions  will  be  entered  via  forms  that  require  their  association  with  a  specific 
survey  version.  When  the  second  survey  is  developed,  all  questions  will  be  available  on 
the  form  in  Figure  9  to  choose  from  as  the  first  question  associated  with  the  survey,  or  the 
user  may  create  a  new  question,  or  version  of  an  existing  question,  using  the  same  form. 
A  similar  form  allows  subsequent  versions  of  existing  surveys  to  be  entered. 
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83  New  Survey 


Figure  9.  Data  Entry  Form  for  the  First  Version  of  a  Survey 


The  other  aspect  of  populating  the  database  involves  the  procedures  for  getting  the 
response  data  into  MCERC.  As  the  USMC  Surveys  are  currently  implemented,  the 
responses  are  appended  to  a  response  database  as  respondents  provide  them.  M&RA 
maintains  this  database  separately  from  other  data  about  the  surveys.  There  is  a  file  for 
responses  to  the  first  version  of  both  the  Exit  and  Retention  surveys.  Data  from  these  files 
must  be  obtained  in  the  format  of  the  RESPONSE  relation  for  establishing  relationships 
between  the  data  and  the  survey  instrument  in  MCERC.  However,  for  analysis,  it  must  be 
converted  into  a  matrix  with  each  row  representing  a  respondent's  set  of  answers  for  an 
entire  survey. 

Data  is  currently  received  for  MCERC  in  the  format  shown  in  Table  5.  This  is  an 
Access  table,  so  it  can  be  related  directly  to  the  tables  in  the  database  to  implement  the 


39 


schema.  It  simply  needs  to  be  imported  into  the  database  first,  then  have  the  appropriate 
relationship  established.  It  can  then  be  queried  along  with  other  tables  to  relate  responses 
back  to  questions  and  surveys.  In  this  initial  implementation  of  MCERC,  the  user  of  the 
system  must  know  which  survey  and  version  the  data  file  is  from.  A  column  must  be 
added  to  the  table  and  populated  with  this  information  to  establish  all  relationships.  Once 
the  database  knows  which  version  of  the  survey  a  response  record  is  for,  it  can  associate 


the  version  of  the  question  that  was  actually  asked  for  that  response. 


Spousjob 

4 

6/12/99  12:07:54  PM 

4530 

Unittype 

T 

6/12/99  12:07:54  PM 

4530 

Qtrssat 

3 

6/12/99  12:07:54  PM 

4530 

Ofambensat 

3 

6/12/99  12:07:54  PM 

4530 

Benedu 

1 

16/12/99  12:07:54  PM 

4530 

Equipwarper 

2 

6/12/99  12:07:54  PM 

4530 

Equipwarunit 

2 

6/12/99  12:07:54  PM 

[4530 

Ocareersat 

3 

6/12/99  12:07:54  PM 

4530 

Unitmotiv 

3 

6/12/99  12:07:54  PM 

4530 

Leadwar 

5 

6/12/99  12:07:54  PM 

4530 

Interfere 

2 

6/12/99  12:07:54  PM 

4530 

Cohere 

4 

6/12/99  12:07:54  PM 

4530 

Ready 

3 

6/12/99  12:07:54  PM 

4530 

jobO 

1 

6/12/99  12:07:54  PM 

4530 

Career20 

1 

6/12/99  12:07:54  PM 

4530 

Rankfactorl 

ben41a 

6/12/99  12:07:54  PM 

4530 

Rankfactor2 

question42 

6/12/99  12:07:54  PM 

4530 

Rankfactor3 

questions 

6/12/99  12:07:54  PM 

4530 

Rankfactor4 

question^ 

6/12/99  12:07:54  PM 

4530 

Rankfactorml 

question117 

6/12/99  12:07:54  PM 

4530 

Rankfactorm2 

question116 

6/12/99  12:07:54  PM 

4530 

Rankfactorm3 

question79 

6/12/99  12:07:54  PM 

4530 

Rankfactorm4 

questioned 

6/12/99  12:07:54  PM 

4530  j 

Gender 

m 

6/12/99  12:07:54  PM  ’ 

4530 

Paygrade 

e8 

6/12/99  12:07:54  PM 

4530 

- j 

Table  5.  Data  Extract  of  Responses  to  USMC  Retention  Census 


A  sample  of  the  actual  data  from  Version  1  of  the  USMC  Retention  Survey  is 
given  in  Table  5.  This  layout  for  the  data  is  clearly  redundant,  with  the  SSN  and 
DateTaken  being  identical  for  all  records  of  one  Marine's  responses.  More  redundancy 
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occurs  when  the  column  is  added  for  the  survey  version,  which  will  be  the  same  for  all 
responses  from  all  respondents  who  take  a  given  version  of  a  survey.  This  redundancy  is 
eliminated  for  the  response  data  analysis  aspect  of  the  system. 
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Table  6.  Subset  of  Response  Data  after  Conversion  from  RESPONSE  Table  Format 


After  conversion,  the  data  is  in  the  general  format  of  Table  6.  However,  there  are 
currently  over  270  columns  required  to  represent  all  questions.  Each  row  of  the  table 
represents  one  respondent's  submission  of  survey  responses.  The  date/time  in  the  second 
column,  combined  with  the  SSN  (last  4  digits)  in  the  first  column,  uniquely  identifies  a 
submission  of  responses  to  one  survey  for  one  respondent.  A  column  must  also  be 
included  which  will  contain  the  Survey  for  which  all  responses  are  submitted.  Under  the 
assumption  that  a  survey  version  is  only  given  during  a  particular  year,  the  date/time  and 
survey  version  might  be  substitutable  as  an  identifier  when  combined  with  the  SSN. 
Clearly,  the  redundancy  of  the  previous  format  is  eliminated  here.  This  format  is 
preferable  for  permanent  storage,  but  the  format  of  the  RESPONSE  table  (similar  to  Table 
5)  must  be  used  for  relating  responses  to  the  survey  instruments  in  the  database. 
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F.  DATABASE  ADMINISTRATION 


Several  issues  need  to  be  considered  on  a  continuing  basis  to  ensure  the  overall 
data  integrity  of  the  database,  particularly  the  responses,  which  compose  the  critical 
information  desired  for  future  analysis.  As  the  system  evolves,  access  via  the  Internet  with 
concurrent,  multiple  users  will  very  likely  become  an  issue.  The  general  issues  of  security, 
protection  and  preservation  of  the  database  needs  to  be  a  primary  concern  of  the  database 
administrator. 


1.  Security 

One  of  the  primary  concerns  for  granting  access  to  MCERC  is  security.  Security 
is  a  two-sided  issue  regarding  the  survey  data.  Data  integrity  must  be  considered  when 
determining  how  the  data  will  be  made  available.  If  certain  users  are  granted  access 
directly  to  the  database,  strict  guidelines  must  be  established  and  followed  to  ensure  the 
data  is  not  rendered  unusable  by  viruses  or  other  malicious  software  that  could  potentially 
be  unleashed  during  a  query  of  the  database.  Privacy  must  also  be  considered,  because  of 
the  information  that  will  be  maintained  on  individual  respondents.  Respondents  must  be 
assured  that  their  responses  will  not  be  traced  back  to  them,  so  they  will  be  more  likely  to 
respond  with  total  honesty  and  candor.  Additionally,  some  may  fear  that  certain  personal 
information  combined  with  their  social  security  number  will  make  them  vulnerable  to  theft 
and  misuse  of  the  information. 

a.  Data  Access 

Good  data  integrity  is  contingent  upon  well-controlled  data  access  to  the 
response  database.  The  data  access  issue  can  be  handled  in  at  least  two  ways.  A  less 
expensive,  but  more  secure  way  is  to  implement  strict  filtering  of  any  queries  on  the 
database.  Parties  requesting  MCERC  information  should  be  granted  access  on  a  limited 
basis.  Users  should  be  required  to  provide  information  that  verifies  who  they  are,  why 
they  need  the  data,  and  what  they  plan  to  do  with  it.  They  may  then  be  issued  a  password 
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and  account  identification  (username,  account  number,  etc.).  Upon  entering  and  querying 
the  system,  each  request  would  be  scanned  by  virus  protection  software.  All  queries 
attempted  would  be  logged  into  an  audit  file  in  order  to  trace  what  information  is  being 
requested  and  by  whom. 

Another  method  for  handling  the  data  access  issue  is  to  allow  no  access 
directly  to  the  stored  data.  In  this  scenario,  all  queries  would  be  handled  by  a  proprietary 
application  for  processing  queries  against  the  database.  Queries  could  be  sent  via  a  web- 
based  front-end  and  pre-screened  and  processed  to  ensure  no  malicious  software  could 
infect  the  data.  There  would  still  be  a  need  to  ensure  authentication  of  users  in  order  to 
enforce  privacy  with  additional  levels  of  authentication  required  for  sensitive  data. 

b.  Privacy 

The  issue  of  privacy  can  be  handled  in  multiple  ways.  Strict  authentication 
and  limiting  access  as  discussed  relative  to  data  integrity  is  one  method,  but  those  with 
access  can  still  potentially  compromise  the  information.  A  better  solution  for  the  privacy 
issue  is  to  ensure  personal  information  maintained  as  data  cannot  be  traced  to  the  actual 
person  submitting  it.  One  way  to  accomplish  this  entails  generating  a  unique  identification 
number  for  each  respondent.  This  generated  user  ID  (GUID)  would  be  permanently 
assigned  to  the  respondent  by  a  linked  list  maintained  at  the  website  which  associates 
specific  identifying  information  (Social  Security  number)  with  the  GUID.  This  table 
would  have  to  be  protected  from  access  as  any  confidential  information  is,  but  would 
provide  specific  identification  of  a  respondent  relative  to  all  responses  submitted  to  the 
Exit  and  Retention  Censuses  without  betraying  the  identity  of  the  respondent. 

Another  possible  solution  is  the  use  of  cryptography  when  the  data  is 
retrieved.  The  data  may  be  maintained  with  private  information,  but  when  it  is  retrieved, 
the  same  algorithm  is  run  only  on  all  "SSN"  fields  retrieved.  Other  data  would  not  be 
encrypted.  Since  the  same  algorithm  encrypts  all  instances  of  "SSN"  retrieved,  all  of  one 
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respondent's  data  will  be  recognizable  as  longitudinal  data  coming  from  a  unique 
respondent. 

To  achieve  data  privacy  and  integrity,  the  basic  requirements  are  that  the 
system  have  secure  communications  between  authenticated  agents.  [Cain,  1999]  In  the 
alternatives  above,  the  authentication  is  handled  prior  to  allowing  access  to  any  data.  The 
communications  interface  between  the  querying  system  and  the  data  must  be  inherently 
secure. 


2.  Database  Backup  and  Recovery 

As  with  any  important  information,  the  MCERC  database  must  be  protected  from 
loss.  The  simplest  way,  giving  the  user  a  flexible  alternative  for  storage  locations,  is  to 
periodically  copy  the  complete  file  to  an  external  storage  device.  This  method  copies  all 
data,  table  structure,  forms,  queries,  etc.  associated  with  the  database.  To  recover  from 
losing  information  in  the  working  file,  the  user  makes  a  copy  from  the  external  storage 
device  back  to  the  working  drive.  However,  all  information  entered  since  the  previous 
save  must  then  be  restored,  so  copying  frequent  backups  to  external  storage  during  data 
entry  is  important. 

Another  approach  to  backup  and  recovery  is  to  maintain  a  copy  of  the  database 
schema  on  disk,  and  only  back  up  the  tables,  since  they  contain  the  desired  data.  This 
procedure  can  be  executed  by  transferring  the  tables  to  an  external  database  file  for 
backup.  To  recover  when  needed,  the  database  schema  can  be  reinstalled  from  disk,  and 
the  procedure  for  transferring  the  tables  performed  on  the  external  file.  This  gives  the  user 
the  structure  of  the  database,  and  all  the  data  from  the  external  file  since  the  last  backup. 
This  procedure  is  somewhat  more  onerous  than  simply  restoring  a  backup. 

There  are  three  potential  scenarios  for  the  database  administrator  to  consider  for 
the  survey  instrument  database.  The  first  is  a  stand-alone  system  maintained  locally  by 
surveyors  who  design  the  surveys.  The  backup  and  recovery  alternatives  discussed  above 
apply  mainly  to  this  scenario,  since  this  is  the  logical  beginning  one  for  MCERC. 
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Another  potential  scenario  is  that  the  database  would  reside  on  a  local  server  and 
be  accessible  by  multiple  users.  If  the  database  were  split,  with  only  the  data  tables 
maintained  on  the  server,  then  only  the  data  tables  would  need  to  be  backed  up  to  an 
external  storage  device.  If  the  server  is  lost,  then  all  data  is  still  available  from  the  last 
backup.  Splitting  the  database  means  it  is  divided  into  two  files:  one  that  contains  the 
tables  and  one  that  contains  the  queries,  forms,  reports,  macros,  and  modules.  By  splitting 
the  database,  users  who  need  to  access  MCERC  can  customize  their  own  forms,  reports, 
and  other  objects  while  maintaining  a  single  source  of  data  on  the  network.  The  database 
administrator  needs  to  ensure  that  there  are  routine  backups  performed  on  the  server  to 
preserve  the  data.  The  normal  procedure  would  be  a  daily  backup  to  an  external  storage 
device  during  off-peak  hours.  Recovery  in  the  event  of  data  loss  would  require  access  to 
the  external  storage  device.  If  transaction  logs  are  kept  for  all  backups  from  the  server, 
and  if  each  user  has  a  transaction  log  recording  their  daily  transactions,  then  users  will 
know  which  of  their  transactions  need  to  be  re-entered  into  the  database  after  the  server  is 
restored. 

The  third  possible  scenario  involves  replication  of  the  database.  Multiple  users  can 
have  a  working  copy  (replica)  of  the  data  files.  Any  changes  made  by  users  are  updated 
when  the  users  connect  to  the  network  with  the  master  database,  called  the  "Design 
Master"  by  Access.  A  replica  can  be  maintained  on  a  network  computer,  effectively 
creating  an  automatic  backup.  Whenever  a  user  of  a  replica  "synchronizes,"  the  changes 
are  updated  to  the  Design  Master,  and  the  updates  from  all  other  replicas  to  the  Design 
Master  are  made  to  the  user's  replica.  Therefore,  in  the  event  of  data  loss,  recovery  can  be 
done  via  the  Design  Master. 

3.  Record  Locking  Strategy 

Because  of  the  large  size  of  the  survey  instrument,  it  is  conceivable  that  MCERC 
could  be  deployed  in  a  multiuser  environment.  Microsoft  Access  can  automatically  prevent 
users  from  changing  records  before  another  user  has  finished  editing  them.  However,  it 
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seems  unlikely  that  multiple  users  would  attempt  to  edit  the  same  record,  so  a  very 
restrictive  record-locking  strategy  is  not  called  for. 

A  good  locking  strategy  for  MCERC  would  allow  users  to  finish  making  changes 
they  have  started.  Since  MCERC  has  a  data  field  for  explanatory  information  about 
versions  of  questions,  this  strategy  would  enhance  collaboration  because  users  can  give 
the  logic  behind  any  editing  done  as  a  basis  for  discussion  should  other  users  have  an 
interest  in  the  edited  record.  The  "Edited  Records"  option  for  a  locking  strategy  locks  the 
record  being  edited,  so  no  other  user  can  change  it.  If  another  user  tries  to  edit  a  record 
that  is  locked,  Access  displays  a  locked  record  indicator.  This  strategy  ensures  that 
changes  once  begun  can  always  be  finished. 
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V.  BUILDING  THE  INTERFACE 


A  good  user  interface  should  make  the  complexities  of  the  database  schema  as 
transparent  as  possible  to  the  user.  For  MCERC,  the  interface  must  not  only  handle  the 
complexities  of  a  large,  longitudinal  system,  but  must  also  provide  the  user  access  to 
analytical  tools.  MCERC  provides  a  link  to  Cognos  Powerplay™  for  crosstabulation 
analysis  of  the  survey  data.  Therefore,  the  user  interface  must  provide  two  main  avenues 
for  the  user:  development  and  management  of  the  survey  instruments  in  Access,  and 
manipulation  and  analysis  of  collected  response  data.  Analysis  can  be  done  within  MCERC 
using  the  link  to  PowerPlay  or  by  generating  a  text  file  for  importation  into  as  statistical 
analysis  the  application. 

For  developing  and  managing  the  survey  instrument,  Access  provides  the 
"Switchboard  Manager"  add-in  which  facilitates  menu  driven  user  interfaces  to  the  forms 
and  reports  the  developer  designs.  It  is  possible  to  use  this  Access  feature  to  run  macros 
that  will  open  other  applications.  For  instance,  Powerplay  can  be  opened  from  the  Access 
switchboard.  Users,  in  general,  will  either  want  to  modify  a  survey  instrument,  or  perform 
some  kinds  of  analyses;  therefore,  the  main  interface  allows  the  user  to  open  Access  or 
Powerplay  as  appropriate.  It  also  provides  a  function  to  first  convert  data  into  a  text  file 
for  analysis  in  Powerplay.  This  text  file  may  be  imported  by  other  statistical  analysis 
applications  such  as  SAS™  or  SPSS™.  When  Access  is  opened,  the  Switchboard  is  used 
for  the  menu  driven  portion  of  the  interface  to  manage  survey  instruments.  Visual  Basic 
6.0  is  used  to  develop  the  main  MCERC  interface  between  Access  and  Powerplay, 
including  the  function  to  prepare  the  data  for  analysis  as  a  response  matrix  in  a  text  file. 

A.  MODELING  THE  PROCESS 

Building  the  Access  database  initially  required  the  analysis  of  entities  and 
relationships,  and  the  creation  of  a  data  model.  Similarly,  the  building  of  the  user  interface 
is  preceded  by  the  development  of  a  process  model.  Once  models  of  the  process  and  sub- 
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processes  are  developed,  the  design  and  implementation  of  an  interface  can  follow  in  a 
structured  manner. 

It  is  essential  to  develop  a  thorough  understanding  of  the  processes  that  must 
logically  occur  in  the  system.  One  method  for  gaining  this  understanding  results  is  to 
simply  think  through  all  processes  desired  of  the  system,  and  determine  what  must  take 
place  to  accomplish  them,  taking  a  step  by  step  approach.  Each  step  of  the  process  is 
visually  represented  as  a  module  beginning  with  the  first  step  and  linking  all  steps  that  can 
then  be  taken.  The  resultant  process  decomposition  diagram  is  a  model  of  the  process 
providing  an  excellent  visual  aid  for  developing  a  user  interface.  It  helps  answer  the 
question  "What  next?"  and  aids  the  developer  in  understanding  the  inputs  and  outputs  of 
each  module.  The  level  of  detail  required  in  a  process  decomposition  diagram  is 
dependent  upon  the  complexity  of  the  requirements  of  the  system  being  developed. 

The  main  process  for  using  MCERC  involves  two  major  avenues,  working  with 
survey  instruments,  and  data  analysis  (Figure  10). 


Figure  10.  Main  Process  Decomposition  Diagram  for  MCERC 
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There  are  clearly  more  levels  of  detail  than  shown  in  Figure  10.  For  the  purpose  of 
developing  a  user  interface  for  MCERC,  there  is  sufficient  detail  beneath  the  "Analyze 
Response  Data"  module  since  the  user  interface  primarily  entails  accessing  the  Cognos 
Powerplay™  software.  Once  there,  the  subsequent  functions  are  accomplished  via  the 
Powerplay  interface,  with  one  exception.  An  interface  for  converting  data  into  a  matrix 
must  be  developed. 

There  is  much  more  detail  needed  beneath  the  "Build  Survey  Instruments"  module, 
however.  Understanding  the  database  schema  and  the  relationships  that  must  be  enforced 
within  it  helps  to  understand  how  the  sub-processes  beneath  these  modules  must  interact. 
Each  of  the  processes  beneath  is  broken  down  further  in  subsequent  process 
decomposition  diagrams. 


Figure  11.  Process  Decomposition  for  Generating  a  New  Survey  in  MCERC 
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The  basic  information  that  goes  in  each  of  the  database  fields  for  surveys 
represents  the  level  of  detail  beneath  the  main  module  in  Figure  11.  The  complicating 
issue  with  simply  defining  a  survey  record  is  the  constraint  that  a  survey  cannot  be  defined 
without  associated  questions.  There  are  actually  three  options  for  doing  this:  Adding  an 
existing  question,  modifying  an  existing  one,  or  generating  a  new  one.  All  three  options 
result  in  the  addition  of  a  question  to  the  survey.  Likewise,  modifying  a  question  becomes 
somewhat  more  complex  when  different  choice  sets  are  assigned.  An  existing  choice  set 
may  be  assigned,  or  a  new  one  defined  and  assigned.  Another  benefit  of  process 
decomposition  is  realized  in  this  diagram.  Note  that  "Assign  ChoiceSet"  appears  twice, 
once  beneath  "Modify  Question"  and  again  beneath  "Generate  New  Question."  When 


Figure  12.  Process  Decomposition  for  Generating  a  New  Version  of  a  Survey 


As  Figure  12  shows,  generating  a  new  version  of  a  survey  is  similar  to  generating  a 
new  survey.  Some  of  the  immediate  sub-processes  are  somewhat  different,  such  as 
retrieving  a  survey  archetype  vice  defining  a  new  one,  assigning  the  next  version  number, 
and  deleting  or  reordering  questions.  However,  this  diagram  shows  that  the  entire  process 
of  adding  questions  is  identical  to  that  of  the  "Generate  New  Survey"  process 
decomposition  diagram.  Therefore,  that  portion  of  the  interface  can  be  re-used  to  support 
both  upper  level  processes  for  building  surveys. 

B.  DESIGN  USER  INTERFACE 

As  the  main  process  decomposition  diagram  shows,  a  logical  starting  point  in 
designing  the  user  interface  process  is  with  the  initial  screen  the  user  will  see  when  using 
MCERC.  For  the  survey  management  aspect  of  MCERC,  the  initial  interface  screen  will 
provide  an  option  for  the  user  to  manage  the  survey  instrument  database,  including 
entering  data  and  retrieving  reports.  As  seen  in  Figure  13,  this  initial  screen  will  also 
provide  access  for  the  user  to  analyze  data  using  PowerPlay,  use  Transformer  to  build  a 
"Powercube"  for  analysis,  or  convert  data  sets  into  the  matrix  format. 
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Figure  13.  Visual  Basic  User  Interface  Screen  for  MCERC 

1.  Survey  Management  Interface 

Upon  selecting  the  "Manage  Surveys"  button  on  the  main  MCERC  form  shown  in 
Figure  13,  Access  opens  the  survey  instrument  database  with  the  menu  in  Figure  14  as  the 
active  screen.  The  user  has  the  choice  to  work  on  surveys,  analyze  data,  view  or  print 
survey  instrument  information,  or  exit  the  system.  Note  also  the  option  to  use  Cognos 
Transformer™  to  create  a  Powercube  for  analysis.  The  option  to  use  either  the  survey 
management  or  data  analysis  aspect  is  available  to  the  user  via  this  button  on  the 
switchboards. 


Figure  14.  MCERC  Menu  Screen  in  Access 

The  first  time  MCERC  is  used,  the  logical  purpose  would  be  to  generate  a  new 
survey.  Figure  9  in  Chapter  IV  displays  the  form  for  this  action,  which  populates  the 
database  with  data.  A  similar  action,  as  developed  in  the  process  decomposition  diagrams, 
is  the  generation  of  a  new  version  of  a  survey.  The  form  designed  for  this  appears  in 
Figure  15. 


Figure  15.  MCERC  Form  for  Entry  of  New  Version  of  an  Existing  Survey 


Survey  Name  and  Previous  Version  are  displayed  in  the  list  box  at  the  top  of  the 
screen.  As  can  be  seen,  the  Retention  survey,  Version  1  is  selected,  and  the  field  labeled 
"New  Vs.  #"  displays  a  "2."  This  field  populates  the  VersionNo  field  of  the 
SURVEYVERS  table  when  the  form  updates  the  tables.  The  "Description"  box  displays 
the  data  from  the  SURVEY  table  describing  the  basic  information  about  the  type  of 
survey.  The  user  may  now  enter  information  about  Version  2  in  the  "Brief  Description  of 
New  Survey"  field  of  the  form.  Also,  the  user  may  document  the  name  of  the  person 
responsible  for  this  version  in  the  "Manager"  field. 

Figure  15  also  illustrates  that  questions  are  associated  with  surveys  as  they  are 
created.  The  user  can  choose  an  existing  question  from  the  list  box,  or  may  select  one  of 
two  buttons  to  either  modify  an  existing  question  or  design  a  new  one.  Once  either  of 
these  two  actions  is  performed,  the  user  returns  to  the  list  box  and  selects  the  new 
question.  The  default  sequence  of  the  question  on  the  new  survey  is  1 0.  By  convention, 
the  sequence  numbers  are  given  in  multiples  of  10,  so  a  default  value  of  1 0  assumes  this  is 


54 


the  first  question  for  the  survey.  The  user  may  identify  a  condition  at  this  time  also, 
meaning  the  presentation  of  this  question  to  a  respondent  may  depend  upon  other 
information  about  the  respondent.  An  example  of  this  for  the  USMC  Surveys  is  "Enlisted 
Only." 

This  form  combines  information  from  five  tables  of  the  database  schema, 
SURVEY,  SURVEYVERS,  QUESTION,  QUESTIONVERS,  and  SURVEYVERS_ 
QUESTIONVERS_X,  the  join  table.  The  design  enforces  the  interrelational  constraints 
between  them,  keeping  the  database  clear  of  excess  records.  Other  MCERC  forms  are 
designed  to  enforce  these  constraints  as  well.  The  use  of  these  forms  is  discussed  in  the 
Maintenance  and  User's  Manual,  Appendix  D. 


A  sub-process  of  generating  new  surveys  and  new  survey  versions  is  initiated  when 
the  user  presses  the  "Create  a  New  Question"  button. 


Figure  16.  Form  for  New  Questions  in  MCERC 


55 


Since  the  form  in  Figure  16  is  for  new  questions,  questions  created  with  this  form 
will  always  be  the  first  version.  The  default  1  for  the  version  number  can  be  seen,  as  can 
the  default  "Version  1  description"  statement  in  the  "Question  Version  Details"  field.  Like 
the  process  decomposition  diagram  showed,  a  new  question  can  have  a  Choice  set 
assigned.  This  Choice  set  can  be  chosen  from  existing  ones  in  the  "Choice  Set"  combo 
box  field,  or  a  new  one  can  be  designed  by  using  the  "New  Choice  Set"  button.  A  very 
similar  form  to  Figure  16  is  used  for  the  making  of  new  versions  of  questions. 

To  design  Choice  sets,  some  flexibility  is  needed.  These  sets  do  not  necessarily 
contain  a  sequential  list  of  Choices.  Some  are  ordered  in  reverse  sequence.  (Figure  2  in 
Chapter  El  displayed  some  examples.)  Some  use  "0"  as  a  value.  Because  of  this,  the  user 
must  enter  the  values  for  Choice  sets.  The  values  entered  are  simply  the  Choice  Set 
identifier,  a  description  of  the  set  if  desired,  and  as  many  Choice  Numbers  with 
corresponding  descriptions  of  each  choice  as  required.  Figure  17  shows  the  form  for  these 
entries. 


Figure  17.  Form  for  Making  New  Choice  Sets  in  MCERC 
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Once  the  user  has  entered  all  information  about  a  survey  instrument  into  MCERC, 
a  report,  called  a  "Codebook,"  can  be  generated  with  all  the  questions  and  their  associated 
choices  for  that  survey  instrument.  From  the  screen  displayed  in  Figure  14,  the  user  may 
select  "View/Print  Survey  Instrument  Information."  This  leads  to  an  option  to  either 
"View/Print"  a  survey  codebook,  return  to  the  main  menu,  or  exit  MCERC.  Once  the 
option  to  print  the  codebook  is  selected,  the  user  is  prompted  for  the  Survey  Name  and 
the  Version  Number,  and  MCERC  generates  a  codebook  on  the  screen  which  the  user 
may  print  if  desired. 

2.  Data  Analysis  Interface 

To  conduct  analysis  on  the  response  data,  there  are  two  main  requirements;  getting 
data  into  the  appropriate  format  for  analysis,  and  using  Powerplay  to  perform 
crosstabulations  analysis.  Data  can  be  obtained  in  its  raw  form,  which  is  the  format 
described  by  the  RESPONSE  object  of  the  MCERC  data  model.  One  response  is  an 
answer  provided  by  one  respondent  to  one  question  on  one  survey  on  a  specific  date.  A 
large  dataset  may  be  composed  of  many  of  these  responses,  representing  many 
respondents'  answers  to  all  appropriate  questions  on  multiple  surveys  on  multiple  dates. 
This  data  must  be  converted  into  a  "flat  file"  or  spreadsheet  format,  with  one  row 
representing  all  of  one  respondent's  answers  to  all  questions  on  one  survey  in  one 
timeframe.  This  can  then  be  imported  into  analytical  software  tools  such  as  SAS™  and 
SPSS™.  The  Visual  Basic  interface  must  provide  the  ability  to  put  the  data  into  this 
format  before  Powerplay  can  be  used.  The  Visual  Basic  code  for  the  procedures  to 
convert  the  data  into  a  spreadsheet  are  included  in  Appendix  C. 

Powerplay  is  used  to  analyze  volumes  of  data  across  multiple  dimensions.  The 
information  must  be  placed  in  multi-dimensional  matrices  according  to  the  variables  the 
analyst  is  examining.  Called  "Powercubes"  by  Cognos,  these  matrices  can  be  designed 
with  a  related  application,  Cognos  Transformer™.  Once  they  are  designed,  the  matrices 
can  be  refreshed  as  additional  data  is  gathered.  Therefore,  the  Visual  Basic  interface  must 
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make  Transformer  available  for  the  user  to  create  desired  Powercubes  from  data,  as  well 
as  facilitate  converting  the  data  into  the  "flat  file"  (spreadsheet)  format. 

To  analyze  response  data  from  MCERC,  the  user  first  needs  to  have  the  data  in  a 
matrix  format.  This  is  initiated  via  the  "Create  Response  Matrix"  button  on  the  main 
MCERC  form  (Figure  13).  Once  this  process  is  completed,  the  user  needs  to  create  a 
Powercube  with  the  dimensions  to  be  analyzed  and  the  measures  desired  for  analyzing  the 
dimension. 

For  the  Retention  survey,  an  example  of  a  Powercube  would  be  to  analyze  the 
MOS  dimension  against  different  measures  of  leadership  quality  from  the  responses 
provided  by  Marines  of  various  MOS's  as  to  their  rating  of  the  quality  of  leadership  of  the 
officers  and  Non-Commissioned  officers.  Defining  certain  communities  of  MOS  skills 
would  allow  multiple  levels  of  "drill-down"  in  this  Powercube.  MOSs  could  be  grouped 
by  aviation,  ground  combat  arms,  logistics,  administrative,  etc.  Marines  of  all  MOSs  will 
provide  responses  rating  the  quality  of  leadership  at  several  levels  (NCO's,  SNCO's, 
Warrant  Officers,  Junior  Officers,  Field  Grade  Officers,  and  General  Officers).  The 
leadership  is  rated  from  Poor  to  Excellent  on  a  scale  of  1  to  5.  Using  the  MOS  as  the 
primary  drill  down  dimension,  and  the  1  to  5  rating  as  the  measure,  this  Powercube  can 
provide  insight  into  how  leadership  is  perceived  overall,  by  different  communities,  and  by 
each  MOS.  An  example  illustrating  how  the  results  would  be  viewed  analyzed  in 
Powerplay  is  shown  in  Figure  1 8. 
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Figure  18.  Example  Cognos  Analysis  of  Quality  Rating  of  Leaders  by  MOS 
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These  numbers  could  be  further  dissected  by  analyzing  them  against  another 
dimension.  For  example,  the  Unit  type  dimension  could  be  in  the  Powercube,  and  the 
numbers  appearing  in  the  above  matrix  would  reflect  the  unit  type  chosen. 

The  MOS  fields  above  are  grouped  by  general  MOS  category.  The  analyst  could 
explore  further  by  drilling  down  on  one  MOS  category  to  see  how  different  MOSs  in  the 
field  rated  leaders.  For  example,  the  0300  MOS  category  represents  the  infantry.  Drilling 
down  would  yield  each  MOS  within  the  infantry  (0302,  0369,  0311,  etc.).  Therefore  it  is 
possible  to  find  out  exactly  how  all  respondents  having  the  same  MOS  rated  each 
category  of  leaders,  and  to  further  break  the  result  down  by  the  type  of  unit  of  the 
respondent.  Still  more  dimensions  can  be  designed  into  Powercubes  if  needed. 

C.  SYSTEM  ARCHITECTURE 

The  process  of  development  results  in  the  MCERC  application  linking  Access, 
Powerplay,  and  Visual  Basic  code  as  an  interface,  as  well  as  a  small  data  manipulation 
program  to  convert  data  into  a  matrix.  The  application  has  been  described  throughout 
this  thesis  in  explanations  of  data  input  and  user  interfaces.  Appendix  C  contains  the 
Visual  Basic  code  for  converting  the  data  into  a  matrix.  Obviously,  the  Cognos 
Powerplay™  software,  including  Transformer,  must  be  installed  for  the  application  to 
have  full  functionality.  Installation  instructions  are  included  in  the  User's  Manual, 
Appendix  D. 

Figure  19  shows  the  MCERC  system  with  its  various  system  architecture 
components  and  their  interconnections.  The  Visual  Basic  interface  component  is  the 
"glue"  that  connects  the  system  as  an  integrated  application.  The  Data  Conversion 
component  supports  analysis  by  formatting  the  data,  and  is  a  subprogram  written  in 
Visual  Basic.  It  receives  input  from  an  external  response  data  file  and  outputs  a  text- 
based  data  file  to  a  designated  location.  This  data  file  can  then  be  used  by  Cognos 
Powerplay  or  imported  into  another  statistical  analysis  application. 
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Figure  19.  MCERC  System  Architecture 

The  Survey  Instrument  Management  in  Microsoft  Access  component  is  opened 
from  the  Visual  Basic  Interface  for  generating  surveys,  questions,  codebooks,  and  other 
survey  management  functions. 

The  Cognos  Powerplay  component  is  also  opened  via  the  interface  to  do  analysis 
or  build  a  Powercube  for  analysis.  The  Data  Conversion  component  first  must  be  used  to 
create  a  text  data  file  in  an  open  location  for  access  by  Powerplay  (or  another  statisical 
analysis  application).  Then  Powerplay  Transformer  is  used  to  build  a  Powercube,  after 
which  the  analysis  can  be  done. 

D.  MAINTENANCE  AND  USER’ S  MANUAL 

To  facilitate  the  administration  and  use  of  MCERC,  a  user's  manual  is  included  as 
Appendix  D.  Procedures  for  installation,  backup,  and  recovery  are  included.  A  step  by 
step  description  of  the  system  processes  is  given  to  guide  the  user  through  all  processes 
included  on  the  process  decomposition  diagram,  except  those  that  pertain  specifically  to 
Cognos  Powerplay™.  A  comprehensive  help  function  is  included  with  the  Cognos 
software  that  need  not  be  duplicated  in  a  User's  Manual. 
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VL  CONCLUSIONS  AND  FUTURE  ENHANCEMENTS 


Conducting  longitudinal  studies  is  not  a  common  practice  in  the  business  world,  so 
there  is  not  a  mass-marketed  survey  development  application  to  support  such  a  project.  A 
proprietary  application  is  necessary  to  ensure  the  concomitant  complexities  can  be 
accommodated  smoothly.  This  research  designed  and  implemented  a  database  system  to 
support  the  longitudinal  aspects  of  the  USMC  Exit  and  Retention  Censuses. 

A.  DESIGN  AND  IMPLEMENTATION  CONCLUSIONS 

The  data  model  developed  for  this  thesis  reflects  the  conceptual  objects  involved  in 
a  longitudinal  survey  system.  Using  archetype/version  objects  to  capture  the  version 
management  aspect  of  the  problem  enhances  the  basic  Survey  and  Question  objects. 
Having  a  large  number  of  questions  on  the  surveys  is  made  easier  by  re-using  the  choices 
associated  with  questions  when  possible,  via  the  CHOICE  SET  object.  The  longitudinal 
aspect  is  captured  by  the  RESPONSE  object,  which  represents  the  elemental  data  for 
which  the  system  is  designed.  With  this  object,  one  person's  response  can  always  be 
traced  to  a  specific  question  on  a  specific  survey  in  a  specific  timeframe. 

The  MCERC  database  schema  implements  a  data  model  to  support  a  longitudinal 
survey  project.  However,  the  inter-relational  constraints  are  not  all  enforceable  by  the 
database  engine  as  they  were  defined.  This  can  be  overcome  by  exercising  control  over 
data  entry  using  validation  rules,  queries  and  coding  to  enforce  the  constraints.  The 
database  schema  allows  for  tracking  changes  in  the  survey  instruments  relative  to  the 
actual  responses  collected  by  them,  thereby  implementing  the  required  support  of  the 
longitudinal  aspect  of  the  survey  system. 

Implementation  of  the  complete  database  by  including  actual  response  data  proved 
to  be  challenging.  Small  subsets  of  the  response  data  obtained  by  the  USMC  to  date  can 
be  retrieved  from  the  response  database  via  the  Internet.  The  format  very  nearly  matches 
the  RESPONSE  table  format,  making  it  fairly  easy  to  relate  to  the  rest  of  the  database. 
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The  conversion  process  developed  in  Visual  Basic  to  convert  the  data  into  a  usable  format 
for  Powerplay  is  very  slow.  However,  it  yields  a  matrix  that  can  be  used  to  do  the  analysis 
for  which  the  surveys  were  intended.  The  link  to  the  Cognos  Powerplay  application 
completes  the  overall  survey  system  by  giving  it  the  necessary  data  analysis  capability. 

B.  RECOMMENDED  FUTURE  ENHANCEMENTS 

The  MCERC  application  delivers  the  basic  capability  to  manage  questions 
forsurveys  as  they  evolve  over  time.  The  relationship  the  database  schema  implements 
between  the  respondent  and  the  survey  instrument  allows  the  tracking  of  a  specific . 
respondents'  answers  across  the  years  and  facilitates  comparison  of  the  responses  with  the 
questions.  As  technology  continues  to  evolve,  this  survey  system  can  be  enhanced  by 
moving  more  and  more  of  the  functionality  into  the  web  environment. 

1.  World  Wide  Web  Accessibility  to  DSS 

During  the  initial  stages  of  the  USMC  Exit  and  Retention  Census  initiative, 
analysis  of  the  data  will  be  done  by  a  limited  number  of  manpower  analysts,  most  of  whom 
are  located  at  M&RA  and  Naval  Postgraduate  School  (NPS).  Over  time,  as  the  volume  of 
data  obtained  increases,  accessibility  to  the  data  and  the  survey  instrument  may  be  of 
interest  to  other  analysts.  The  Department  of  Defense  as  well  as  other  services  facing 
issues  similar  to  those  of  the  USMC,  will  likely  be  interested  in  the  data.  Universities 
other  than  NPS  may  assist  in  the  research  or  use  the  longitudinal  data  for  academic 
purposes.  Policy  studies  organizations,  "think  tanks,"  may  use  the  data  to  develop  and 
justify  positions  on  military  policy  issues.  Therefore  an  area  for  future  consideration  is 
integrating  the  web-based  survey  into  a  single  environment  running  exclusively  on  the 
Internet. 


a.  Issues 

A  key  concern  for  allowing  Internet  access  to  MCERC  is  security. 
Security  was  discussed  in  Chapter  IV,  but  takes  on  added  significance  in  a  web-based 
environment.  The  issues  are  essentially  the  same,  but  a  broader  range  of  protections  must 
be  considered.  Anti-virus  software  must  be  kept  strictly  up  to  date.  The  network 
connectivity  to  the  system  will  need  to  be  maintained  for  accessibility,  but  access  must  be 
restricted  to  those  who  have  a  valid  requirement  for  access. 

Another  issue  related  to  making  MCERC  web-accessible  is  the  system 
architecture.  How  to  obtain  data  extracts,  i.e.,  whether  to  download  data  subsets  and 
store  them  locally  vs.  building  and  maintaining  Powercubes  on  the  remote  server,  and 
whether  to  have  MCERC  reside  on  a  server  or  on  the  desktop  are  decisions  that  need  to 
be  made  relative  to  this  architecture. 

An  attractive  solution  for  obtaining  data  subsets  is  to  access  them  remotely 
using  the  Cognos  Powerplay  software.  The  Powercubes  can  be  built,  maintained  and 
refreshed  on  the  server.  For  an  analyst  to  use  the  data,  they  would  merely  need  to  know 
the  remote  locations  of  the  Powercubes  and  be  granted  access.  This  would  prevent 
proliferation  of  large  amounts  of  duplicate  data  in  various  locations,  and  would  allow  for 
efficient  transfer  of  the  desired  information.  Rather  than  transferring  all  raw  data,  only  the 
desired  report,  or  aggregated  data  subset  would  be  stored  locally  by  analysts. 

If  multiple  individuals  will  be  using  MCERC  for  analyzing  the  survey 
instrument  against  the  data,  or  are  collaborating  on  survey  design,  it  may  become  desirable 
to  put  MCERC  on  a  server  and  have  it  accessible  via  the  web.  Assuming  these  analysts 
are  geographically  separated,  this  would  facilitate  collaboration,  thereby  speeding  the 
process  of  developing  and  maintaining  the  surveys. 
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b.  Feasibility 


Rendering  MCERC  accessible  via  the  web  is  definitely  feasible.  The 
Access  application  can  be  converted  to  Hypertext  Markup  Language  (HTML)  or 
Extensible  Markup  Language  (XML)  using  web-authoring  tools  as  these  types  of  tools 
become  increasingly  easy  to  use.  Authorization  could  be  granted  to  a  limited  number  of 
developers  to  use  data  entry  forms  and  collaborate  on  survey  development  if  desired. 
Broader  access  could  be  granted  for  users  desiring  to  pull  reports  from  the  database,  such 
as  listings  of  questions  for  a  survey. 

The  data  collected  by  the  USMC  Exit  and  Retention  Surveys  can  certainly 
be  made  web-accessible.  Online  Analytical  Processing  (OLAP)  applications  such  as 
Powerplay  Server  Web  Edition  allow  Powercubes  to  be  deployed  across  the  web.  There 
are  a  growing  number  of  OLAP  software  solutions  available  which  will  clearly  facilitate 
this  objective.  [Cognos] 

As  online  technologies  continue  to  proliferate,  the  feasibility  of  providing 
web  access  to  MCERC  will  undoubtedly  increase.  Because  the  Exit  and  Retention  Census 
initiative  is  still  in  its  initial  stages,  it  remains  to  be  seen  as  to  whether  it  will  be  practical 
and  desirable  to  implement  web  access.  Nonetheless,  courses  of  action  should  be 
considered  in  preparation  for  this  event. 

2.  Full  Integration  of  System  Components 

MCERC  brings  the  components  of  a  web-based  survey  system  together  without 
fully  integrating  them.  A  recommended  future  enhancement  is  the  integration  of  the 
survey  instrument  database  with  a  web-authoring  capability.  This  enhancement  would 
facilitate  the  publication  of  a  survey  to  the  web  directly  from  the  database,  i.e.,  a  new 
version  of  a  survey  would  be  designed  with  all  features  being  recognizable  in  a  web-based 
language.  The  generation  of  a  report  using  this  language  would  allow  it  to  be  published 
without  having  to  re-enter  any  of  the  questions  into  the  web  pages  and  with  only  limited 
coding. 
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The  statistical  analysis  aspect  of  the  system  could  also  be  integrated  with  the 
survey  instrument  database.  This  integration  would  simplify  the  association  of  various 
versions  of  questions  with  the  time-series  analyses  done  on  the  variables.  Co-locating  the 
survey  instrument  database  with  the  response  database  and  relating  the  responses 
permanently  to  the  instrument  would  facilitate  having  quick  and  understandable  analyses 
of  the  data. 

C.  CONCLUSION 

The  Microsoft  Access  design  and  implementation  of  the  MCERC  database 
demonstrates  the  feasibility  of  building  a  system  to  support  a  complex,  long  term  project 
like  the  USMC  Exit  and  Retention  Censuses.  The  database  schema,  with  its  version 
management  capabilities,  provides  a  way  to  track  a  dynamic,  longitudinal  survey 
instrument  by  relating  responses  to  the  survey  instruments  with  the  appropriate  survey, 
and  associated  question  versions.  This  combination  of  data  and  metadata  in  a  single 
database  with  links  to  independent  analytical  software  tools  results  in  an  integrated 
environment  for  supporting  survey  administration  and  analysis. 
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APPENDIX  A.  MASTER  FILE  DATA 
NPS  USMC  Retention  Survey.  September  14, 1999 
CODEBOOK 

The  following  variables  marked  by  a  *  will  be  integrated  from  the  master  file;  need  exact  variable 
names  or  file  locators  in  the  master  file: 

♦GENDER 
*LOS 

♦DUTYSTA 
♦COMSOURCE 
*PMOS 
♦AMOS 
♦DUTYMOS 
♦PAYGRADE 
♦TGRADE 
♦ENTRYAGE 
♦AFOT 

*  PERFORMRTG 

RESPONSE  FORMATS 


Time  in  active  duty  Service  (or  date  entered  active  duly  service  if  not  available) 
Current  duty  station 
Commissioning  source  (officer  only) 

Primary  military  occupational  specialty 
Alternate  MOS 


Time  in  current  grade  (or  date  of  rank  if  not  available) 

Entry  Age  (or  date  entered  active  duty  service  if  not  available) 
(enlisted  only) 

“Performance  measures”  (These  will  be  identified  from  other  files) 


Satisfaction  Response  Format: 

4.  Very  satisfied 

3.  Somewhat  satisfied 

2.  Somewhat  dissatisfied 

1.  Very  dissatisfied 

Agree  Response  Format: 

4.  Strongly  agree 

3.  Somewhat  agree 

2.  Somewhat  disagree 

1.  Strongly  disagree 

Frequency  Response  Format: 

5.  Never 

4.  Seldom 

3.  Some  of  the  time 

2.  Most  of  the  time 
1.  All  of  the  time 
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Quality  Response  Format: 

5.  Excellent 

4.  Very  good 

3.  Good 

2.  Poor 

1.  Very  poor 

Probability  Response  Format: 

1.  0%  (no  chance) 

2.  10%  (very  slight  possibility) 

3.  20%  (slight  possibility) 

4.  30%  (some  possibility) 

5.  40%  (fair  possibility) 

6.  50%  (fairly  good  possibility) 

7.  60%  (good  possibility) 

8.  70%  (probable) 

9.  80%  (very  probable) 

10.  90%  (almost  sure) 

11.  100%  (certain) 


USMC  RETENTION  CENSUS 

This  survey  will  take  approximately  30  minutes.  The  information  in  this  census  will  remain 
confidential.  It  will  not  be  used  to  identify  individuals.  The  results  will  be  used  only  to  report  trends. 
Your  sincere  responses  are  needed  to  help  improve  decisions  affecting  Marine  Corps  Personnel. 

VARIABLE  NAME  (NPS)  USMCname 


DEMOGRAPHICS 

DUNTTTYP  unitype 


What  is  the  type  of  unit  you  are  currently  assigned  to? 


1.  Base/station 

2.  Division/Regiment/Battalion 

3.  Drill  instructor/Sgt.  Instructor  OCS 

4.  Embassy 

5.  MSG 

6.  HQMC/MCCDC 

7.  Instructor  (MOS) 

8.  Joint  duty 

9.  Marine  Barracks/MCSF 

10.  Marine  support  battalion 

11.  Recruiting  duty 


12.  Wing/Group  Squadron 

13.  Reserve  support 

14.  FSSG/Battalion/Company 

15.  Ship’s  company 

16.  SRIG 

17.  MEU  Staff 

18.  Training  support 

19.  Long  term  schools/ 
Training  (greater  than 
6  months) 

20.  Other-not  listed 
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DDEPLOY  deploystat 

What  is  your  current  deployment  status? 

1.  I’m  currently  dqployed 

2.  I’m  not  currently  deployed,  but  have  deployed  in  the  last  12  months 

3.  Neither  of  the  above 

DRENLST  (Enlisted  only)  reenl_advstat 

How  many  times  have  you  reenlisted  in  the  Marine  Corps?  (Please  do  not  include  extensions) 

1.  I  have  never  reenlisted 

2.  I  have  reenlisted  once 

3.  I  have  reenlisted  twice 

4.  I  have  reenlisted  three  or  more  times 

NOTE:  Combined  with  DPROMO  as  single  field  with  multiple  entries,  reenl_advstat. 
DPROMO  (E5  and  above  only)  reenl_advstat 

To  the  best  of  your  knowledge,  what  is  your  current  promotion/advancement  status? 
NCOOFF1  I’m  not  yet  in  zone 

NCOOFF2  I’ll  be  in  primary  zone  for  the  next  promotion  board 

NCOOFF3  I’ve  been  selected  for  promotion 

NCOOFF4  I’ve  been  passed  over  once  for  promotion 

NCOOFF5  I’ve  been  passed  over  two  or  more  times  for  promotion 

NOTE:  Combined  with  DRENLST  as  single  field  with  multiple  entires,  reenl_advstat. 

DEDUCeduc 

What  is  your  highest  level  of  education? 

1.  Less  than  high  school  degree 

2.  HS  equivalency  (e.g.,  GED,  certificate  of  completion) 

3.  High  school  diploma 

4.  Less  than  one  year  of  college 

5.  One  or  more  years  college,  no  degree 

6.  Associate’s  degree 

7.  Bachelor’s  degree 

8.  Master’s  degree 

9.  Doctoral  or  professional  degree 


DMARITL 


marital 


What  is  your  current  marital  status? 

1.  Single  and  never  married 

2.  Single  and  divorced 

3.  Legally  separated 

4.  Married  (first  marriage) 

5.  Married  (previously  divorced  or  widowed) 

6.  Widowed 

DDEPNS  depns 

How  many  dependent  children  do  you  have?  (Highlight  your  selection). 

0 

1 

2 

3 

4 

5 

6 

7 

8 

9+ 

DSCHOOL  (DDEPNS>0  only)  school 

My  child(ren)  attend  the  following  type(s)  of  schools:  (check  all  that  apply) 

1.  I  have  no  children  of  school  age 

2.  Civilian  (public  school) 

3.  Private  or  parochial  school 

4.  DoD  school  (overseas  DoD-operated  school) 

5.  DoDDES  school  (continental  U.S.  DoD-operated  school) 

6.  Home  school 

7.  College 

8.  Trade  school 

NOTE:  Multiple  entries  are  separated  by  commas. 

DMILHOU  milhousing 

Do  you  live  in  military  housing? 

1.  Yes 
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2.  No 

NOTE:  Code  is  character. 


BRACE  race 

What  is  your  race/ethnicity?  (Y ou  may  select  more  than  one  if  you  have  a  combined  racial/ethnic 
heritage). 

1.  White/Caucasian 

2.  Black/African  American 

3.  Asian  or  Pacific  Islander  (Filipino,  Guamanian,  etc.) 

4.  Hispanic/Latino/Spanish  descent 

5.  Native  American,  including  American  Indian,  Aleut,  Inuit,  and  Eskimo 

6.  Other  race/ethnic  group 

NOTE:  Multiple  entries  are  separated  by  commas. 

DRELIG  religion 

What  is  your  religious  preference? 

1.  No  religious  preference 

2.  Catholic 

3.  Protestant  (Baptist,  Methodist,  Lutheran,  etc.) 

4.  Mormon 

5.  Jewish 

6.  Orthodox  Christian  (Greek,  Russian,  etc.) 

7.  Muslim 

8.  Buddhist 

9.  Hindu 

10.  Atheist 

11.  Agnostic 

12.  Some  other  religion 

PSPJOB  (DMARITL=4  or  5  only)spousjob  (Mark  all  that  apply) 

What  is  your  spouse’s  employment  situation? 

1.  My  spouse  works  full  time  in  a  civilian  job 

2.  My  spouse  works  part  time  in  a  civilian  job 

3.  My  spouse  is  unemployed,  but  actively  seeking  employment 

4.  My  spouse  works  in  the  home  (homemaker) 

5.  My  spouse  works  at  home  (self-employed) 

6.  My  spouse  is  a  student 

7.  My  spouse  is  active  duty  military 

NOTE:  Multiple  entries  axe  separated  by  commas. 

FAMILY  ENVIRONMENT  AND  PERSONAL  LIFE 
FSPRLOC  (DMARITL=4  or  5  only)  spoucareer 
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To  what  extent  have  your  spouse’s  career  opportunities  been  limited  by  frequency  of  relocation? 

1.  Not  at  all 

2.  Somewhat 

3.  A  great  deal 

FSPDLOC  (DMARITAL=4  or  5  only)  spouloca 

To  what  extent  have  your  spouse’s  career  opportunities  been  limited  by  duty  location? 

1.  Not  at  all 

2.  Somewhat 

3.  A  great  deal 

FSCHLSAT  (DDEPNS>0  only)  schoolsat 

How  satisfied  are  you  with  the  school  system(s)  your  children  use?  [Satisfaction  response  format 
with  additional  response  category,  n/a] 

FDYCARAV  (DDEPNS>0  only)  daycare 

How  satisfied  are  you  with  the  availability  of  daycare  in  your  area?  [Satisfaction  response  format 
with  additional  response  category,  n/a] 

FD Y CARO  U  (DDEPNS>0  only)  daycaresat 

How  satisfied  are  you  with  the  quality  of  the  day  care  you  use?  [Satisfaction  response  format 
with  additional  response  category,  n/a] 

FD Y C ARC  O  (DDEPENS>0  only)  daycarecost 

How  satisfied  are  you  with  the  cost  of  daycare  in  your  area?  [Satisfaction  response  format  with 
additional  response  category,  n/a] 

FDENTAL  (DMARITL=4  or  5  and  DSPJOB  *6;  or  DDEPNS>0)  dentaldepsat 

How  satisfied  are  you  with  the  dependent  dental  insurance  program?  [Satisfaction  response 
format] 

FMEDAV  (DMARITL=4  or  5  and  DSPJOB  *6;  or  DDEPNS>0)  medfamavail 

How  satisfied  are  you  with  the  availability  of  FAMILY  medical  care?  [Satisfaction  response 
format] 

FMEDOU  (DMARITL=4  or  5  and  DSPJOB*6;  or  DDEPNS>0)  medfamqual 

How  satisfied  are  you  with  the  quality  of  FAMILY  medical  care?  [Satisfaction  response  format] 
FOTRSAT  qtrssat 

How  satisfied  are  you  with  your  current  housing?  [Satisfaction  response  format] 
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FOTRAY 


qtrsgov 


How  satisfied  are  you  with  the  AVAILABILITY  of  government  quarters?  [Satisfaction  response 
format] 

FOTRSAF  qtrssafe 

How  satisfied  are  you  with  the  safety  and  security  of  your  housing  neighborhood?  [Satisfaction 
response  format] 

FAMTIME  (DMAJRITL=4  or  5  or  DDEPNSX))  famtime 

How  satisfied  are  you  with  your  balance  of  work  and  family  time?  [Satisfaction  response  format] 

FOBEN  (DMARITL=4  or  5  or  DDEPNS>0)  ofambensat 

Overall,  how  satisfied  are  you  with  the  benefits  and  programs  for  families  provided  by  the 
Marine  Corps?  [Satisfaction  response  format] 

PAY  &  BENEFITS 

BPENTAL  dentalsat 

How  satisfied  are  you  with  YOUR  dental  care?  [Satisfaction  response  format] 

BMEDAV  medavail 

How  satisfied  are  you  with  the  availability  of  YOUR  medical  care?  [Satisfaction  response 
format] 

BMEDO  medqual 

How  satisfied  are  you  with  the  quality  of  YOUR  medical  care?  [Satisfaction  response  format] 

BBAH  bah 

How  satisfied  are  you  with  the  amount  you  receive  for  your  Basic  Housing  Allowance?  (BAH, 
which  used  to  be  known  as  VHA  and  BAQ,  is  designed  to  pay  80%  of  your  housing  costs) 
[Satisfaction  response  format] 

BBASPAY  basepaysat 

How  satisfied  are  you  with  the  amount  of  your  base  pay?  [Satisfaction  response  format] 
BSLPAYAV  spclpayavail 
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How  satisfied  are  you  with  the  availability  of  special  pays,  such  as  bonuses  or  special  duty 
assignment  pay?  [Satisfaction  response  format] 

BSPAYAM  spclpaysat 

How  satisfied  are  you  with  the  amount  of  special  pays,  such  as  bonuses  or  special  duty 
assignment  pay?  [Satisfaction  response  format  with  additional  response  category,  5  not 
applicable] 


BPCS  pcssat 

How  satisfied  are  you  with  the  amount  of  reimbursement  for  PCS  moves?  [Satisfaction  response 
format] 

BRENLTBO  (Enlisted  only)  reelist  (?) 

(Not  applicable  for  officers) 

How  satisfied  are  you  with  the  amount  available  for  re-enlistment  bonuses?  [Satisfaction 
response  format] 

BTOTPAY  milcompsat 

How  satisfied  are  you  with  your  total  military  compensation?  [Satisfaction  response  format] 

BMWR  benmwr 

How  satisfied  are  you  with  MWR  benefits?  [Satisfaction  response  format] 

BEDUCbenedii 

How  satisfied  are  you  with  your  educational  benefits?  [Satisfaction  response  format] 

BRETC  benretire 

How  satisfied  are  you  with  retirement  benefits  as  outlined  under  current  law?[Satisfaction 
response  format] 


BTREND  benefitsa 

Generally,  my  observation  is  that  benefits  are: 

1.  Greatly  improving 

2,  Improving 
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3.  Staying  the  same 

4.  Slowly  eroding 

5.  Being  severely  cot 


BOBEN  obensat 

Overall,  how  satisfied  are  yon  with  YOUR  benefits?  [Satisfaction  response  format] 

BOPAYopaysat 

Overall,  how  satisfied  are  yon  with  YOUR  pay?  [Satisfaction  response  format] 

JOB-RELATED  QUESTIONS 

JCURR  iobsat 

How  satisfied  are  you  with  your  current  job  assignment?  [Satisfaction  response  format] 

JPMOS  pmossat 

How  satisfied  are  you  with  the  extent  to  which  you  are  assigned  to  jobs  within  your  primary 
MOS?  [Satisfaction  response  format] 

JCHAL  chaljobsat 

How  satisfied  are  you  with  the  level  of  challenge  in  your  current  job?  [Satisfaction  response 

format] 

JHOURS  workhrsat 

How  satisfied  are  you  with  the  number  of  hours  you  are  required  to  work?  [Satisfaction  response 
format] 

JAUTH  authorsat 

How  satisfied  are  you  with  the  authority  you  are  given  to  do  your  job?  [Satisfaction  response 
format] 

JRESP  responsat 

How  satisfied  are  you  with  the  level  of  responsibility  in  your  current  job?  [Satisfaction  response 

format] 

JEXPECT  expect 

Are  you  doing  the  things  you  expected  to  be  doing  when  you  ORIGINALLY  joined  the  Marine 

Corps? 
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1.  Yes 

2.  No 

0.  I  had  no  expectations  regarding  my  job  as  a  Marine 

JCNTRTB  helpgoals 

I  feel  my  contributions  help  my  unit  accomplish  its  mission 
[Agree  response  format] 

JU  STAFF  understf 

How  often  have  you  had  to  “pick  up  the  load”  due  to  the 
unit  being  understaffed? 

[Frequency  response  format] 


JWKFAIR  workfair 

How  often  have  you  had  to  “pick  up  the  load”  because  seniors  in  the  chain  of  command  don’t 
assign  work  fairly?  [Frequency  response  format] 

JO  JOB  ojobsat 

Overall,  how  satisfied  are  you  with  your  current  military  job  and  working  conditions? 
[Satisfaction  response  format] 


TRAINING  and  EQUIPMENT 
TREAD  Y  trainready 

I  have  received  the  training  needed  to  make  my  contribution  to  unit  readiness.  [Agree  response 
format] 

TNEW  trainnew 

Recruit/initial  training  is  fully  adequate.  [Agree  response  format] 

TMOS  trainmos 

MOS  training  is  fully  adequate.  [Agree  response  format] 

TOJT  trainojt 

On-the-job-training  is  fully  adequate.  [Agree  response  format] 

TPME  trainpme 

Professional  Military  Education  is  fully  adequate.  [Agree  response  format] 
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TEXER 


trainexercise 


Effective  training  occurs  during  exercises.  [Agree  response  format] 

TCMBT  traincmbt 

Combat  skills  training  is  fully  adequate.  [Agree  response  format] 

TNUNIT  trainunit 

Unit-level  training  (not  combat  skills)  is  fully  adequate.  [Agree  response  format] 

TEOPP  equipwarper 

My  unit  has  the  necessary  personal  equipment  (782  gear,  personal  weapons,  special  clothing, 
etc.)  to  accomplish  our  mission.  [Agree  response  format] 


TEOPU  equipwarunit 

My  unit  has  the  necessary  unit  equipment  (crew  served  weapons,  comm  gear,  vehicles,  aircraft, 
computers,  etc.)  to  accomplish  our  mission.  [Agree  response  format] 

TEOPNEE  equipnee 

(You  are  not  required  to  answer  this  question). What  equipment  do  you  need?  Please  list 
representative  items  below. 


TO  TRAIN  otrainsat 

Overall,  how  satisfied  are  you  with  your  Marine  Corps  training  and  equipment?  [Satisfaction 
response  format] 

TOEOP  oequipsat 

Overall,  how  satisfied  are  you  with  your  Marine  Corps  equipment?  [Satisfaction  response 
format] 


CAREER 

CASIGN  assignsat 

How  satisfied  are  you  with  your  ability  to  have  some  influence  over  your  assignments  in  the 
Marine  Corps?  [Satisfaction  response  format] 

CSECUR  jobsecsat 

How  satisfied  are  you  with  your  job  security  in  the  Marine  Corps?  [Satisfaction  response  format] 


CADVOP  advoppsat 
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How  satisfied  are  you  with  your  opportunities  for  promotion  and  advancement  in  the  Marine 
Corps?  [Satisfaction  response  format] 

CDEV  careerdevsat 

How  satisfied  are  you  with  your  opportunities  for  career  development  (training  education)  in  the 
Marine  Corps?  [Satisfaction  response  format] 

CSPSUP  (DMARITL=4  or  5  only)  jobsatsp 

My  spouse  encourages  me  to  continue  my  career  in  the  Marine  Corps  .  [Agree  response  format] 
IAfrAIN  maragain 

If  I  had  to  do  it  over.  I’d  again  choose  to  be  a  United  States  Marine.  [Agree  response  format] 

IRECOM  marrec 

I’d  recommend  joining  the  Marine  corps  to  a  friend  or  relative.  [Agree  response  format] 

CPROMO  promotfair 

Promotions  in  the  Marine  Corps  are  based  on  effective  performance,  competence,  and  published 
Marine  Corps  standards  (e.g.,  PME,  height/weight)  [Agree  response  format] 

CPROMOP  promoprb 

“What  do  you  think  your  chances  are  of  being  promoted  to  the  next  higher  grade?  (If  you  are 
planning  to  leave  active  duty  Marine  Corps  service,  please  answer  as  though  you  were  staying.) 
[Probability  response  format  with  additional  response  category,  n/a,  does  not  apply] 

COCREER  ocareersat 

Overall,  how  satisfied  are  you  with  career  opportunities  in  the  Marine  Corps?  [Satisfaction 
response  format] 

READINESS.  WORK  ENVIRONMENT.  MORAT.F  TCMPn 
CTMPO  op  tempo 

For  me  personally,  the  operations  tempo  (i.e.,  number  of  deployments,  exercises,  contingencies) 
is: 

5.  Much  too  high 
4.  A  little  too  high 
3.  About  right 
2.  A  little  too  low 
1.  Much  too  low 

FAWAY  timeaway 
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How  much  accumulated  time  have  your  Marine  Corps  duties  required  you  to  be  away  from  home 
during  the  past  year?  Include  all  field  time,  other  training,  FMF  duty  and  TAD  that  required  you 
to  be  away  from  your  barracks  or  home  for  periods  of  more  than  24  hours. 

1.  None  at  all 

2.  1  week  -  3  months 

3.  4-6months 

4.  7  -  9  months 

5.  9-12  months 

SOWNUP  mistakresp 

In  my  unit,  when  mistakes  occur,  those  involved  take  responsibility. 

1.  Never 

2.  Seldom 

3.  Some  of  the  time 

4.  Most  of  the  time 

5.  All  of  the  time 

SZERO  zerodef cmd 

How  often  have  you  felt  that  a  “zero-defect”  standard  (i.e.,  any  mistake,  however  minor,  could 
jeopardize  your  career)  was  applied  to  you  or  others  in  your  unit  during  the  last  year? 

1.  Never 

2.  Seldom 

3.  Some  of  the  time 

4.  Most  of  the  time 

5.  All  ofthe  time 

SRACE  cmdreseth 


How  satisfied  are  you  with  your  command’s  response  to  instances  of  racial/ethnic  discrimination? 
[Satisfaction  response  format  with  additional  response  category,  5,  not  applicable,  no 
discrimination  observed  or  experienced] 

SGENDER  cmdresgndr 

How  satisfied  are  you  with  your  command’s  response  to  instances  of  gender  discrimination  or 
sexual  harassment?[Satisfaction  response  format  with  additional  response  category,  5,  not 
applicable,  no  discrimination  observed  or  experienced] 

SREL1G  cmdresrel 

How  satisfied  are  you  with  your  command’s  response  to  instances  of  religious  discrimination? 
[Satisfaction  response  format  with  additional  response  category,  5,  not  applicable,  no 
discrimination  observed  or  experienced] 
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SMORAL 


unitmotiv 


The  morale  in  my  unit  is: 

5.  Very  high 
4.  High 
3.  Moderate 
2.  Low 
1.  Very  low 

S  READY  unitready 

My  unit’s  level  of  readiness  can  best  be  described  as:  [Quality  response  format] 
SREADYT  unitreadytrend 

My  unit’s  level  of  readiness  is: 

1.  decreasing 

2.  staying  the  same 

3.  increasing 

SPUBLIC  publicsup 

Most  Americans  support  the  USMC.  [Agree  response  format] 

LEADERSHIP 


How  would  you  rate  the  quality  of  leadership  of  the  following: 

LGENOF 

leadgen 

LFLDOF 

leadfield 

LJROF 

leadjr 

LWAROF 

leadwar 

LSNCO 

leadsnco 

LNCO 

[Quality  response  format] 

leadnco 

LGOALS  commgoals 

My  immediate  seniors  clearly  communicate  goals  and  plans  for  what  this  unit  will  achieve  under 
their  command.  [Agree  response  format] 

LEVTUT  listenrec 

My  immediate  seniors  listen  to  and  consider  my  input.  [Agree  response  format] 

LLEARN  learn 

My  immediate  seniors  develop,  encourage,  and  facilitate  learning.  [Agree  response  format] 
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LSUBOR  respect 

My  immediate  seniors  show  respect  for  subordinates.  [Agree  response  format] 

LCOMM  inform 

My  immediate  seniors  keep  people  informed  about  issues  affecting  them.  [Agree  response  format] 

LRECOG  perform 

My  immediate  seniors  recognize  and  reward  good  performance.  [Agree  response  format] 

LFAIR  fair 

My  immediate  seniors  enforce  performance  standards  fairly.  [Agree  response  format] 

LXTRNG  interfere 

My  immediate  seniors  try  to  see  that  outside  demands  do  not  interfere  with  our  scheduled 
training.  [Agree  response  format] 

L1NNOV  inovate 

My  immediate  seniors  encourage  innovation.  [Agree  response  format] 

LTECHtech 

My  immediate  seniors  have  the  technical  knowledge  and  military  skills  needed  to  be  successful  in 
this  command.  [Agree  response  format] 

LFOCUS  unitgood 

My  immediate  seniors  put  the  good  of  the  unit  above  personal  ambition.  [Agree  response  format] 
LEXPECT  expectperf 

My  immediate  seniors  clearly  explain  what  is  expected  in  my  performance.  [Agree  response 
format] 

LRESOU  resource 

My  immediate  seniors  try  to  see  that  we  have  the  resources  to  do  our  jobs.  [Agree  response 
format] 

LSUPP  support 

My  immediate  seniors  support  my  career  development.  [Agree  response  format] 
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LCOHER 


cohere 


My  immediate  seniors  encourage  unit  cohesiveness .  [Agree  response  format] 

LMLEAD  takelead 

My  immediate  seniors  encourage  me  to  take  on  leadership  responsibilities.  [Agree  response 
format] 

LREADY  ready 

My  immediate  seniors  keep  us  focused  on  unit  readiness.  [Agree  response  format] 

LMODEL  Ieadbehav 

My  immediate  seniors  demonstrate,  through  personal  example,  high  standards  of  behavior  and 
ethics.  [Agree  response  format] 

LOPENTJ  opencandidunit 

My  immediate  seniors  encourage  open  and  candid  discussion  about  unit  problems.  [Agree 
response  format] 


LOPENP  opencandidper 

My  immediate  seniors  encourage  open  and  candid  discussion  about  personal  problems. 
[Agree  response  format] 

LFDBKfeedbacsat 

My  immediate  seniors  give  clear  and  timely  feedback  on  my  individual  performance. 

[Agree  response  format] 

LREWRD  bestreward 

Rewards  and  recognition  are  given  to  those  who  deserve  them  in  my  unit 
[Agree  response  format] 

PLEAD  oleadersat 

Overall,  how  satisfied  are  you  with  Marine  Corps  leadership?  [Satisfaction  response  format] 

CIVILIAN  EMPLOYMENT  OPPORTUNITIES 
ESRCH  jobsearch 

Have  you  actively  looked  for  civilian  employment  in  the  past  12  months? 
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1.  Yes 
0.  No 


EOFFER  joboffer 

In  the  past  12  months,  have  you  received  any  civilian  job  offers? 

1.  Yes 
0.  No 

F.SKTI  J  ,S  jobskills 

I  have  gained  skills  in  the  Marine  Corps  that  are  highly  marketable  for  civilian  employment. 
[Agree  response  format] 


EPROB  probgoodjob 

If  you  were  to  leave  the  service  now,  how  likely  would  you  be  to  find  a  good  civilian  job? 

0.  0%  (no  chance)  , 

1.  10%  (very  slight  possibility) 

2.  20%  (slight  possibility) 

3.  30%  (some  possibility) 

4.  40%  (fair  possibility) 

5.  50%  (fairly  good  possibility) 

6.  60%  (good  possibility) 

7.  70%  (probable) 

8.  80%  (very  probable) 

9.  90%  (almost  sure) 

10.  100%  (certain) 

INTENTIONS/EXPECTATIONS 
ICREERE  (enlisted  only)  careerintentenl 

Which  of  the  following  statements  best  describes  your  career  intentions  at  this  time? 
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1.  I  intend  to  stay  on  active  duty  until  retirement  eligible 

2.  I  intend  to  stay  on  active  duty  beyond  retirement  eligibility 

3.  I  intend  to  stay  on  active  duty,  but  not  until  retirement 

4.  I’m  not  sure  what  I  intend  to  do. 

5.  I  intend  to  leave  the  Marine  Corps  at  my  EAS. 

6.  I’d  like  to  stay  on  active  duty  but  I’m  not  able  to  renew  my  contract  at  my  EAS/ECC 

7.  I’m  being  involuntarily  separated  before  reaching  my  EAS. 

8.  I’m  voluntarily  leaving  before  my  EAS  (early  release  for  education,  hardship  discharge,  etc.) 
ICKEERO  (officers  only)  careerintentofc 

Which  of  the  following  statements  best  describes  your  career  intentions  at  this  time? 

1.  I  intend  to  stay  on  active  duty  until  retirement  eligible 

2.  I  intend  to  stay  on  active  duly  beyond  retirement  eligibility 

3.  I  intend  to  stay  on  active  duty,  but  not  until  retirement 

4.  I’m  not  sure  what  I  intend  to  do. 

5.  I  intend  to  leave  the  Marine  Corps  voluntarily  at  the  end  of  my  current  obligation. 

6.  I’d  like  to  stay  on  active  duty  but  I’m  not  able  to  augment 

7.  I’m  being  involuntarily  separated 

8.  I’m  voluntarily  leaving  before  my  EAS  or  end  of  current  obligation  (early  release  for 
education,  hardship  discharge,  etc.) 


IRENLST  (enlisted  only  )  reenlistenl  (?) 

How  likely  are  you  to  re-enlist  at  the  end  of  your  current  term  of  service? 

1.  Does  not  apply,  I  plan  to  retire 

2.  Does  not  apply,  I  plan  to  leave  active  duty  service 

[Probability  response  format  with  additional  response  categories] 

IAUGMNT  (Officers  only)  augment 

How  likely  are  you  to  apply  for  augmentation  in  the  regular  Marine  Corps?  [Probability  response 
format  with  additional  response  category,  0,  does  not  apply,  I  am  already  a  regular  officer] 

IYEARS  intentyrs 

When  you  finally  leave  the  Marine  Corps,  how  many  years  do  you  expect  to  have  served  on  active 
duty? 

1  11  21 

2  12  22 
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3 

13 

23 

4 

14 

24 

5 

15 

25 

6 

16 

26 

7 

17 

27 

8 

18 

28 

9 

19 

20 

10 

20 

30+ 

UNYOL  involsep 

How  likely  are  you  to  be  involuntarily  separated  before  you  desire  to  leave  the  Marine  Corps? 
[Probability  response  format] 

IOBLIG  (officers  only)  curroblig 

How  many  months  do  you  have  left  in  your  current  obligation? 

0,  indef.  I  have  no  current  obligation 
1-6 
6-12 
12-24 
24+ 

ICURENL  (enlisted  only)  currenl 

How  soon  will  you  complete  your  current  enlistment  contract  or  extension? 

1-6  months 
6-12  months 
12  -  24  months 
24+  months 

NOTE:  Should  not  appear  on  officer  survey. 

IRESRV  reserve 

When  you  finally  leave  active  duty,  do  you  plan  to  join  a  Marine  Corps  reserve  unit? 

6.  Does  not  apply,  I  am  not  eligible  to  join 

5.  Definitely  yes 

4.  Probably  yes 

3.  Don’t  know/ not  sure 

2.  Probably  no 

1.  Definitely  no 


OVERALL  SATISFACTION 


OSATMC  osatmc 

Overall,  how  satisfied  are  you  with  the  Marine  Corps?  [Satisfaction  response  format] 

IMPORTANCE  FACTORS 
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Regardless  of  your  career  plans  with  the  Marine  Corps,  there  are  probably  things  that  make  you 
want  to  STAY  in  the  Marine  Corps  and  other  things  that  make  you  want  to  LEAVE.  Even  if  you  plan  to 
stay  until  retirement,  there  may  be  aspects  of  your  career  that  sometimes  make  you  consider  leaving. 
Likewise,  if  you  plan  to  leave  the  Marine  Coips,  there  are  probably  things  about  being  a  Marine  that  you 
have  enjoyed  and  that  you  would  miss.  The  purpose  of  the  last  two  sections  of  this  survey  is  to  identify 
BOTH  of  these  sets  of  factors. 

How  important  are  each  of  the  following  to  your  desire  to  leave  the  Marine  Corps? 

4.  very  important 
3.  important 
2.  somewhat  important 
1.  not  important 

Instructions:  Rate  each  factor  in  the  following  list  in  terms  of  the  extent  to  which  it  would  make  a 
contribution  to  your  desire  to  leave  active  duty  service  in  the  Marine  Corps.  A  later  part  of  the  census  will 
allow  you  to  identify  the  aspects  of  your  life/career  in  the  Marine  Corps  that  would  have  a  positive  effect 
on  your  desire  to  stay  on  active  duty  service. 

Job 

UCURR  Current  job  assignment 

LJFUTR  Anticipated  future  job  assignments 

LJWKLD  Fairness  of  distribution  of  workload 

LJPEERS  Marines  I  work  with  currently 

LJHOURS  Number  of  hours  required  by  work 

LJRESPH  Level  of  responsibility  in  my  current  job  assignment:  too  high 

bJRESPL  Level  of  responsibility  in  my  current  job  assignment:  too  low 

LJAUTH  Authority  to  do  my  job  effectively 

LJFUBK  Feedback  on  my  job  performance 

UCHALH  Work  too  challenging 

LJCHALL  Work  not  challenging  enough 

LJTRAIN  Availability  of  training  to  do  my  job  effectively 

LJEOUIP  Availability  of  equipment  to  do  my  job  effectively 

Career 

LCADVOP  Advancement  opportunities 

LCPROMO  Promotion  fairness 

LCSECUR  Job  security 

LCUSEMC  Changes  in  the  way  the  Marine  Corps  is  being  utilized 

LCDEV Opportunities  for  career  development  (training  education) 

LMONIT  Interaction  with  monitors 

LCPMOS  Desirability  of  primary  MOS 

LCMOSOP  Limited  career  opportunities  in  my  primary  MOS 
LCXMOS  Limited  career  opportunities  outside  my  primary  MOS 

LCCIV  Career  opportunities  in  the  civilian  sector 

LCCMBAT  Opportunity  for  combat  training 

LCUTRNG  Opportunities  for  unit  level  training 

LCQTRNG  Quality  of  training 

LCTMPOH  Optempo  (number  of  contingencies,  deployments,  exercises):  too  high 

LCTMPOL  Optempo  (number  of  contingencies,  deployments,  exercises):  too  low 


jobO 

jobl 

job2 

job3 

job4 

job5 

job6 

job7 

job8 

job9 

joblO 

jobll 

jobl2 

careerl3 

careerl4 

careerlS 

careerl6 

careerl7 

careerl8 

careerl9 

career20 

career21 

career22 

career23 

career24 

career25 

careeropta26 

careeroptb27 


Family  Environment  and  Personal  Life 


LFDLOCC 

Current  duty  location 

famenvperlife28 

LFDLOCF 

Anticipated  future  duty  location 

famenvperlife29 

LFMOVEF 

Frequency  of  moves 

famenvperlife30 

LFMOVES 

Impact  of  frequency  of  moves  on  spouse  career 

famenvperlife3 1 

LFLOCS 

Impact  of  duty  station  location  on  spouse’s  career 

famenvperlife32 

LFMOVEC 

Impact  of  frequency  of  moves  on  children’s  education 

famenvperlife33 

LFAWAY 

Time  away  from  home/family 

famenvperlife34 

LFFREE 

Limitations  on  personal  freedom 

famenvperlife35 

LFFSSA 

Availability  of  family  support  services 

famenvperlife36 

LFFSSO 

Quality  of  family  support  services 

famenvperlife37 

LFREC  Quality  of  recreational  services 

famenvperlife38 

LFHOUAV 

Availability  of  housing 

famenvperlife39 

LFHOUO 

Quality  of  housing 

famenvperlife40 

Benefits 

LBRETC 

Current  retirements 

benef!ts41 

LBRETF 

Possible  changes  to  future  retirement  benefits 

benefits42 

LBMEDC 

Current  medical/dental  benefits 

benefits43 

LBNEDF 

Possible  changes  to  medical/dental  benefits 

benefit$44 

LFMED 

Current  medical/dental  benefits  for  families 

benefits44a 

LBPAYC 

Current  pay 

beneftts45 

LBPAYF 

Anticipated  future  pay 

benefits46 

LBEDUC 

Educational  benefits 

benef!ts46a 

LBINCAV 

Availability  of  incentive  pay  (e.g.,  bonuses) 

beneflts47 

LBENCAM 

Amount  available  of  incentive  pay  (e.g.  bonuses) 

benefits48 

Leadership 

LLGENOF 

LLFLDOF 

LLJROF 

LLWAROF 

LLSNCO 

LLNCO 

LSMORAL 

LLSUBOR 

LLTECH 

LLFOCUS 


LLCOMM 

LLINPUT 


Culture 


The  quality  of  General  officer  leadership 

The  quality  of  Field  grade  (Maj,  Lt  Col,  Col)  leadership 

The  quality  of  Jr.  officer  (Capt,  Lt)  leadership 

The  quality  of  warrant  officer  leadership 

The  quality  of  SNCO  leadership 

The  quality  of  NCO  leadership 

Unit  morale 

Immediate  seniors’  treatment  of  subordinates 
Immediate  seniors’  technical  competence 

Immediate  seniors’  focus  on  personal  advancement  versus  the  good 
of  the  unit 

Communication  to  marines  about  issues  affecting  them 
Immediate  seniors’  consideration  of  input  from  individual  marines 


leadership49 

leadershipSO 

leadership51 

leadership52 

leadership53 

leadership54 

leadership55 

leadership56 

Ieadership57 

leadership58 

leadership59 

leadership60 


87 


LSPUBLIG  Public  support  for  USMC  culture61 

LSFITH  Physical  fitness  standards:  too  high  culture62 

LSFITLPhysical  fitness  standards:  too  low  culture63 

LSAPPRH  Personal  appearance  standards:  too  high  cnlture64 

LSAPPRL  Personal  appearance  standards:  too  low  cultured 

LSMORLH  Moral  standards:  too  high  culture66 

LSMORLL  Moral  standards:  too  low  culture  67 

LSZERO  Zero  defects  standard  of  performance  (low  tolerance  for  mistakes)  culture68 

LSXTRNG  Outside  demands  that  interfere  with  training  culture69 

LSRACE  Racial  discrimination  culture70 

LSGENDR  Gender  discrimination  culture71 

LSRELIG  Religious  discrimination  culture72 


Please  list  any  other  features  that  would  contribute  to  your  desire  to  leave  active  duty  service  ONLY 
IF  you  would  rate  them  as  “very  important”  to  your  decision.  '  " 

L WRITE  1  #1 

LWRITE2  #2 

LWRITE3  #3 

LWRITE4  #4 

[Note:  construct  a  list  of  factors  rated  as  “very  important”;  or  “important”  if  the  preceding  list  is  a 
“null  set”] 

Instructions:  Those  factors  that  you  identified  as  most  important  that  would  affect  your  decision  to  leave 
active  duty  Marine  Corps  are  listed  below.  Rank  order  the  top  four  that  would  influence  you  to  leave: 
LRANK1  Most  important  factor  in  desire  to  leave  rankfactorl 

LRANK2  Second  most  important  factor  in  desire  to  leave  rankfactor2 

LRANK3  Third  most  important  factor  in  desire  to  leave  rankfactor3 

LRANK4  Fourth  most  important  in  desire  to  leave.  rankfactor4 

Note:  Responses  appear  in  the  database  as  “question _ ”  where _ is  the  number  at  the  right  edge  of 

the  USMC  name  or  writeinfl  -  writeinf4. 

Instructions:  Rate  each  factor  in  the  following  list  in  terms  of  the  extent  to  which  it  would  malfp  a 
positive  contribution  to  your  desire  to  stay  on  active  duty  service  in  the  Marine  Corps. 

How  important  is  each  of  the  following  to  your  desire  to  stay  in  the  Marine  Corps? 


4.  Very  important 
3.  Important 
2.  Somewhat  important 
1.  Not  important 

Job 

SJCURR  Current  job  assignment  jobm73 

SJFUTR  Anticipated  future  job  assignments  jobm74 

SJPEERS  Marines  I  work  with  currently  jobm75 

SJRESP  Level  of  responsibility  I  am  given  jobm76 

SJAUTH  Authrority  to  do  my  job  effectively  jobm77 

SJFDBK  Feedback  on  my  job  performance  jobm78 

SJCELAL  Challenging  work  jobm79 


-9  if  no  response! 
-9  if  no  response! 
-9  if  no  response! 
-9  if  no  response! 


_writeinfl 

_writeinf2 

_writeinf3 

writeinf4 
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Career 

SCADVOP  Advancement  opportunities 

SCSECUR  Security 

SCMTSSN  Participation  in  the  mission  of  the  Marine  Corps 

SCDEV  Opportunities  for  career  development  (training,  education) 
SCMGMT  Career  management 

SCOPPMC  Career  opportunities  in  the  Marine  Corps 
SCPMOS  Primary  MOS  job  assignments 

SCXPMOS  Non-primary  MOS  job  assignments 

SCCMBAT  Opportunity  for  combat  training 

SCTMPO  Optempo  (number  of  contingencies,  deployments, 

and  exercises) 

Family  Environment  and  Personal  Life 
SFDLOCC  Current  duty  location 

SFLOCO  Opportunity  to  serve  in  other  duty  locations 
SFMOVEF  Frequency  of  moves 

SFFSS  Family  support  services 

SFREC  Recreational  services 
SFTVTHOTT  Access  to  military  housing 


careerm80 

careerm81 

careerm82 

careerm83 

careerm84 

careerm85 

careerm86 

careerm87 

careerm88 

careerm89 


famenvperlifem90 
f amenvperlifem9 1 
famenvperlifem92 
famenvperlifem93 
famenvperlifem94 
famenvperlifem95 


Benefits 

SBRET  Retirement  benefits  benefitsm96 

SBMED  Medical/dental  benefits  benefitsm97 

SBPAY  Military  pay  benefitsm98 

SBINC  Amount  and  availability  of  incentive  pay  (e.g.,  bonuses)  benefitsm99 


Leadership 

SLGENOF  The  quality  of  General  officer  leadership 
SLFLDOF  The  quality  of  Field  grade  (Maj,  LtCol,  Col)  leadership 

SLJROF  The  quality  of  Jr.  officer  (Capt,  Lt)  leadership 

SLWAROF  The  quality  of  Warrant  officer  leadership 
SLSNCO  The  quality  of  SNCO  leadership 

SLNCOThe  quality  of  NCO  leadership 
SSUNITP  Unit  cohesion  and  pride 

SLSUBOR  Immediate  seniors’  treatment  of  subordinates 

SLTECH  Immediate  seniors’  technical  competence 

SLFOCUS  Immediate  seniors’  focus  on  the  good  of  the  unit  versus 
advancement 


leadershipmlOO 

leadershipmlOl 

leadershipml02 

leadershipml03 

leadershipml04 

leadershipml05 

leadershipmlOfi 

leadershipml07 

leadershipml08 

personal 

leadershipm!09 


SLCOMM  Communication  to  marines  about  issues  affecting  them  leadershipml  10 
sr.TNPTTT  Immediate  seniors’ consideration  of  input  from  individual  marines  leadershipmlll 
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Culture 
SSPUBLIC 
SSFIT 
SSAPPR 
SSMORL 
SSSERVE 
SSPRIDE 
SSTRAVEL 
SS  WOMEN 
SSM3NOR 
SSFRNDS 


Public  support  for  USMC  culturell2 

Physical  fitness  standards  culturell3 

Personal  appearance  standards  culturell4 

Moral  standards  culturell5 

Chance  to  serve  country  culturell6 

Pride  in  being  an  active  duty  Marine  culturell7 

Opportunity  to  travel  culturell8 

Opportunities  for  women  in  the  Marine  Corps  culturell9 

Opportunities  for  racial/ethnic  group  minorities  in  the  Marine  Corps  culturel20 
Friendships  and  acquaintances  culturel21 


SuHsrtT*™*  0  HSt  °f  faCt°rS  ratCd  38  "***  important”;  or  “™Portant”  If  the  preceding  list  is  a 


Instructions:  Those  factors  that  you  identified  as  most  important  to  your  desire  to  stay  on  active  duty 
service  in  the  Marine  Corps  are  listed  below.  Rank  order  the  top  four: 

SRANK1  Most  important  factor  in  desire  to  stay  rankfactorml 

SRANK2  Second  most  important  factor  in  desire  to  stay  rankfactorm2 

SRANK3  Third  most  important  factor  in  desire  to  stay  rankfactorm3 

Fourth  most  important  factor  in  desire  to  stay.  rankfactorm4 


Note:  Responses  appear  in  the  database  as  “question _ ”  where _ is  the  number  at  the  right  edge  of 

the  USMC  name  or  writeinfl  -  writeinf4 
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APPENDIX  B.  DATA  DICTIONARY 

This  data  dictionary  for  the  MCERC  database  is  organized  as  follows: 

A.  Table/Relation  definitions:  Provides  an  overview  and  purpose  of  each  table  in 
alphabetical  order,  their  basic  elements,  and  their  identifying  characteristics. 

B.  Field  definitions:  Provides  specific  information  about  each  field  in  the  database, 
including  data  type,  field  length,  uniqueness,  indexing.  Information  is  provided  as 
a  view  of  each  field  within  the  table  definition  from  Microsoft  Access™.  The 
fields  are  arranged  in  the  sequence  they  appear  within  the  tables,  with  the  tables 
arranges  in  alphabetical  order. 

A.  Table/Relation  Definitions 


CHOICESET 

The  CHOICE_SET  table  contains  only  the  identifier  of  a  set  of  choices  and 
a  description  of  the  set.  It  relates  to  a  repeating  group  of  choices 
represented  by  the  CHOICE_SET_Choice  table. 


CHOICESETChoice 

The  CHOICE_SET_Choice  table  contains  a  repeating  set  of  choices, 
representing  the  responses  a  respondent  may  choose  from  when  taking  a 
survey.  The  identifier  is  a  composite  key  with  the  CHOICE_SET  table 
identifier  as  a  foreign  key  and  each  Choice  number  for  a  set  as  the  unique 
key. 


QUESTION 

The  QUESTION  table  contains  only  the  basic  elements  of  a  question.  It  is 
the  archetype  of  a  version  of  a  question.  As  such,  it  only  contains  the 
identifying  information  of  questions;  the  description  and  the  identifier/key. 


QUESTIONVERS 

The  QUESTIONVERS  table  contains  specific  information  about  a  version 
of  a  question.  The  archetype  of  QUESTIONVERS  is  QUESTION.  Thus 
it  represents  related  instances  of  an  instance  of  QUESTION.  Records  in  it 
are  identified  by  the  combination  of  the  key  of  QUESTION  as  a  foreign 
key,  and  a  version  numberfield. 
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RESPONDENT 

The  RESPONDENT  table  contains  information  about  each  respondent 
who  takes  a  survey.  The  unique  identifier  is  the  Social  Security  Number 
(SSN)  of  the  respondent.  Other  information  includes  demographics  and 
personal  information. 


RESPONSE 

The  RESPONSE  table  contains  information  about  each  response  a 
respondent  makes.  The  unique  identifier  for  each  record  is  composed  of 
foreign  keys  from  the  RESPONDENT,  SURVEYVERS,  and 
QUESTIONVERS  tables,  plus  the  Datestamp  field.  The  only  other 
information  in  this  table  is  the  choice  the  respondent  provides  in  response 
to  a  particular  question  on  a  particular  survey  on  a  particular  date. 

SURVEY 

The  SURVEY  table  contains  only  the  basic  elements  of  a  survey.  It  is  the 
archetype  of  a  version  of  a  survey.  As  such,  it  only  contains  the  identifying 
information  of  surveys;  the  description  and  the  identifier/key. 


SURVEYVERS 

The  SURVEYVERS  table  contains  specific  information  about  a  version  of 
a  survey.  The  archetype  of  SURVEYVERS  is  SURVEY.  Thus  it 
represents  related  instances  of  an  instance  of  SURVEY.  Records  in  it  are 
identified  by  the  combination  of  the  key  of  SURVEY  as  a  foreign  key,  and 
a  version  numberfield. 


SURVEYVERS_QUESTIONVERS_X 

The  SURVEYVERS_QUESTIONVERS_X  table  is  the  junction  table  that 
results  from  the  many-to-many  relationship  between  SURVEYVERS  and 
QUESTIONVERS.  As  such,  it  contains  foreign  keys  from 
SURVEYVERS  and  QUESTIONVERS.  In  addition,  it  contains  fields 
unique  to  the  union  of  the  two  tables. 
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CHOICESET.ChoiceSetDescription 
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CHOICE_SET_Choice.ChoiceDescription 


QUESTION.QuestionName 


QUESTION.Description 


i 
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QUESTIONVERS.QuestionVersionID_QuestionName_FK 


QUESTIONVERS.QuestionVersionID.VersionNo 
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QUESTIONVERS  .ED_ 


99 


QUESTIONVERS .  ChoiceSetID  FK 


RESPONDENT.Demographics_Gender 
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RESPONSE.  SURVEYVERS  ID  FK 
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RESPON SE.  QUES  TIONVERS  ID  FK 


RESPONSE.DateStamp 


\  SE  SURVEY:  Table  . . . .  _  £[£[0 


SURVEY.  SurveyName 
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SURVEYVERS .  Survey V  ersionID_SurveyName_FK 
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SURVEYVERS  .V  sDetail 
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SURVEYVERS  .Manager 
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SURVEYVERS_QUESTIONVERS_X.  SURVEYVERSJD_FK 


SURVEYVERS_QUESTIONVERS_X.QUESTIONVERS_ID_FK 


SURVEYVERS_QUESTIONVERS_X.  Condition 
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APPENDIX  C.  APPLICATION  CODE 


This  appendix  contains  the  application  code  for  the  data  conversion  program  of  MCERC. 

The  code  is  written  using  Visual  Basic,  version  6.0.  It  converts  data  from  the  4  column 
table  format  of  a  MS  Access™  table  received  from  the  response  database,  to  the  response 
matrix  format  required  for  a  statistical  analysis  application.  It  allows  saving  the  reponse 
matrix  in  either  MSExcel™  or  a  comma-delimited  ASCII  text  file. 


CODE: 


Private  Sub  cmdClose_Click{ ) 

End  Sub 

Private  Sub  ASCII_Click( ) 

If  ASCII. Value  =  True  Then 
Excel. Value  =  False 

Label 3 .Caption  =  "Saving  Data  to  ASCII  File" 

End  If 
End  Sub 

Private  Sub  CommandButton2_Click ( ) 

'  Public  Matrixl (0  To  1000,  0  To  205)  As  String  'excel  sheets  have  a  255  column 

Dim  Matrix2 ( 0  To  1000,  0  To  100)  As  Soring  'maximum  so  we  have  to  span 
'  Dim  singleRowl (0  To  205)  As  String  'multiple  sheets  these  one 

Dim  singleRow2  (0  To  100)  As  String  'dimension  arrays  are  used 

'to  speed  the  transfer  to  excel 


Dim  BigMatrix(0  To  1000,  0  To  300)  As  String  'Used  for  ASCII  format 
Dim  textOut  As  String  'used  to  speed  file  transfer 


Dim  xlApp  As  Object 
Dim  spreadsheets lumn  As  Integer 
Dim  spreadsheetRow  As  Integer ~ 
Dim  count  As  Long 
Dim  i  As  Integer 
Dim  n  As  Integer 


Processed  =  True 


ProgressBarl .Max  =  datQuestRS .Recordset . SecordCount  -  1 
For  n  =  0  To  datQuestRS. Recordset .RecordCount  -  I 
MSHFlexGrid2 .Row  =  n  +  1 


If  n  <=  203  Then. 

Matrixl  (0,  n  +  2)  as  MSHFlexGr id2  . Text 
Else:  Matrix2 ( 0 ,  n  +  2  -  204)  =  MSH?lexGrid2 .Text 
End  If 


'label  the  columns 


ProgressBarl. Value  =  n 


ProgressBarl .Max  —  datRespRS -Recordset.  .RecordCount  'label  the  rows 

For  n  =  0  To  da tRespRS . Recordset .RecordCount  -  1 

MSHFlexGrid3 .Row  =  n  +  1 

MSHFlexGrid3.Col  =  0 

Matrixl (n  +1,0)=  MSHFlexGrid3 .Text 

Matrix2 (n  +  1,  0)  =  MSHFlexGrid3 .Text 

MSHFlexGrid3 .Col  =  1 

Matrixl (n  +  1,  1)  =  MSHFlexGrid3 . Text 

Matrix2 (n  +  1,  1)  =  MSHFlexGrid3 .Text 

ProgressBarl .Value  =  n 

Next  n 


Matrixl (0,  0)  =  "Last  4  of  ssn" 
Matrix2(0,  0)  =  "Last  4  of  ssn" 
Matrixl (0,  1)  =  "date /time" 
Matrix2 (0,  1)  =  "date/time" 


'  populate  matrix  with  data 


MatrixColumn  =  0 
MatrixRow  =  0 
count  =  1 


ProgressBar2 .Max  =  datPrimaryRS . Recordset .RecordCount 
datPrimaryRS . Recordset . MoveFirs  t 

Do  While  count  <=  datPrimaryRS. Recordset .RecordCount 
ProgressBar2 . Value  =  count 


If  (datPrimaryRS .Recordset .Fields !3) .Value  =  Matrixl (MatrixRow,  0) 

Or  datPrimaryRS .Recordset . Fields ( 3 ) .Value  =  Matrix2 (MatrixRow,  0))  Then 


Do  While  MatrixColumn  <  206 


do  the  ssn's  match? 


If  (datPrimaryRS. Recordset. Fields (2 ) 


Matrixl (MatrixRow,  MatrixColumn) 
count  =  count  +  1 
datPrimaryRS . Recordset . MoveNext 

End  If 


.Value  =  Matrixl (0,  MatrixColumn))  Then 

'  do  the  questions  match? 

=  datPrimaryRS .Recordset .Fields (1) .Value 
'  and  increment  the  count 
'  (get  next  question) 


MatrixColumn  =  MatrixColumn 
Loop 


'move  to  next  column  in  Matrix 


-  1) 


Do  While  (MatrixColumn  >=  206)  Ar.c  (MatrixColumn  <  datQuestRS .Recordset .RecordCount 


If  (datPrimaryRS  .Recordset .  Fields  i )  .Value 
MSHFlexGridl . Col  =  1 

Matrix2  (MatrixRow,  MatrixColurn:  -  206) 
count  »  count  +  1 
End  If 


=  Matrix2 (0,  MatrixColumn  -  206))  Then 
'do  the  questions  match? 
if  so,  set  the  cell  with  answer 
=  datPrimaryRS . Recordset . Fields ( 1 ) .Value 
'and  increment  the  count 
' (get  next  question) 


MatrixColumn  =  MatrixColumn  +  1 
Loop 


'move  to  next  column  in  Matrix 


If  MatrixColumn  -  datQuestRS .Recordset .RecordCount  -  1  Then 
MatrixColumn  =  0 
count  =  count  +  1 
datPrimaryRS . Recordset . MoveNext 
End  If 
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Else:  MatrixRow  =  MatrixRow  + 
End  If 
Loop 


if  the  ssn's  don't  match 
go  to  the  next  row 
in  spreadsheet 


transfer  data  to  excel 


If  Excel. Value  =  True  Then 

Set  xlApp  =  CreateObject ( "Excel .Application" ) 

xlApp. Visible  =  True 

Set  xlbook  =  xlApp. Workbooks .Ada 

Set  xlSheetl  =  xlbook. Workshee cs ( "Sheetl" ) 

Set  xlSheet2  =  xlbook. Wor kshee ts ( Hsheet2" ) 

ProgressBar3 .Max  =  datRespRS .Recordset .RecordCount  -  1 

For  n  =  0  To  datRespRS’. Recordset  .RecordCount  -  1 
For  i  =  0  To  205 

singleRowl  (i)  =  MatrixKr.,  L) 

Next  i 

For  i  =  0  To  100 

singleRow2 (i)  =  Matrix2(n,  %) 

Next  i 

xlApp . Sheets ( " sheetl " ) . Range { xlApp . Co 1 1 s ( n  +  1 ,  1 ) . Address ,  _ 

xlApp. Cells (n  +  1,  UBound{ singleRowl) ) .Address) .Value  =  singleRowl 

xlApp. Sheets ( "sheet2" ) .Range (xlApp. Cells (n  +  1,  1) .Address,  _ 

xlApp. Cells (n  +  1,  UBound ( sing 1 eRow2) ) .Address) .Value  =  singleRow2 

ProgressBar3 .Value  =  n 

Next  n 
End  If 

transfer  data  to  ASCII  File 


If  ASCII. Value  =  True  Then 

Dim  fso,  txtfile 

Set  fso  =  CreateObject ( "Scripting . FileSystemObject" ) 

Set  txtfile  =  fso.CreateTextFiie { "f: \MajSmith\testfile.txt" ,  True) 

ProgressBar3 .Max  =  datRespRS .Recordset . RecordCount  -  1 

For  n  =  0  To  datRespRS. Recordset .RecordCount  -  1 

For  i  =  0  To  205  'to  optimize,  make  output  line 

txtOut  =  Matrixl(n,  i)  " ,  "  'length  as  close  to  255  characters 
txtfile. Write  (txtOut)  'as  possible 

Next  i 

For  i  =  3  To  datQuestRS .Records ex .RecordCount  -  204  'skip  first  three  lines 
txtOut  =  Matrix2  (n,  i)  +  •* ,  " 
txtfile. Write  (txtOut) 

Next  i 

txtfile. WriteLine  (Matrix2 (n,  i  -  1))  'last  line  in  row  gets 

'a  newline  character 
'vice  a  comma 

ProgressBar3 .Value  =  n 

Next  n 

txtfile. Close 
End  If 
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End  Sub 


Private  Sub  Excel_Click( ) 

If  Excel. Value  =  True  Then 
ASCII. Value  =  False 

Label 3 .Caption  =  "Saving  Data  to  Excel" 
End  If 

End  Sub 


Private  Sub  Form_Load() 

Me. Left  =  GetSetting(App .Title,  "Settings",  "MainLeft" ,  1000) 
Me. Top  =  GetSetting(App. Title,  "Settings",  "MainTop",  1000) 
Me. Width  =  11000  ' 

Me. Height  =  8000 

datPrimaryRS. Visible  =  False 

With  MSHFlexGridl 


.Redraw  =  False 

.ColWidth(O)  =  -1 
.  -ColWidth (1)  =  -1 
.ColWidth{2)  =  -1 
.ColWidth (3)  s  -1 

.AllowBigSelection  =  True 
-FillStyle  =  f lexFillRepeat 

.Row  =  0 
.Col  =  0 

.RowSel  =  .FixedRows  -  1 
.ColSel  =  .Cols  -  1 
.CellFontBold  =  True 

.AllowBigSelection  =  False 
.FillStyle  =  f lexFillSingle 
.Redraw  =  True 

End  With 


set  grid's  column  widths 


set  grid's  style 


make  header  bold 


da tQuestRS. Visible  =  False 
With  MSHFlexGrid2 
.Redraw  =  False 
. ColWidth (0)  s  1500 


set  grid's  column  widths 


.AllowBigSelection  =  True 
.FillStyle  =  f lexFillRepeat 


set  grid's  style 


_  .  '  make  header  bold 

.Row  =  0 

.Col  =  0 

.RowSel  =  .FixedRows  -  1 
.ColSel  =  .Cols  -  1 
.CellFontBold  =  True 

.AllowBigSelection  =  False 
.FillStyle  =  f lexFillSingle 
.Redraw  =  True 

End  With 

da tRespRS. Visible  =  False 

With  MSHFlexGrid3 
.Redraw  »  False 


.  ColWidth (0)  =  600 
. ColWidth (1)  s  1100 
.Width  =  2000 


'  set  grid's  column  widths 


'  set  grid's  style 

.AllowBigSelection  =  True 
.FillStyle  =  f lexFillRepea t 

'  make  header  bold 

.Row  =  0 
.Col  =  0 

.Rows el  =  .FixedRows  -  1 
.ColSel  =  .Cols  -  1 
.CellFontBold  =  True 

.AllowBigSelection  =  False 
.FillStyle  =  f lexFillSingle 
.Redraw  =  True 

End  With 
End  Sub 

Private  Sub  Form_Unload (Cancel  As  Integer': 

Dim  i  As  Integer 

'close  all  sub  forms 

For  i  =  Forms. count  -  1  To  1  Step  -1 
Unload  Forms (i) 

Next 

If  Me.WindowState  <>  vbMinimizec  Then 

SaveSetting  App. Title,  "Settings",  "MainLef t ■ ,  Me. Left 
SaveSetting  App. Title,  "Settings",  "MainTop",  Me. Top 
SaveSetting  App. Title,  "Settings",  "MainWidth" ,  Me. Width 
SaveSetting  App. Title,  "Settincrs",  "MainHeight" ,  Me. Height 
End  If 
End  Sub 

Private  Sub  tbToolBar_JButtonClick (ByVal  Hit:  on  As  MSComCtlLib. Button) 

On  Error  Resume  Next 

Select  Case  Button. Key 

Case  "New" 

'ToDo:  Add  'New'  button  code. 


MsgBox  "Add  'New'  button  code.’' 
Case  "Open" 


'ToDo:  Add  'Open'  button  code. 


MsgBox  "Add  'Open'  button  code." 
Case  "Save" 


'ToDo:  Add  'Save'  button  code. 


MsgBox  "Add  'Save'  button  code." 

Case  "Print" 

'ToDo:  Add  'Print'  button  code. 

MsgBox  "Add  'Print'  button  code." 

Case  "Cut" 

'ToDo:  Add  'Cut'  button  code. 


MsgBox  "Add  'Cut'  button  code." 

Case  "Copy" 

'ToDo:  Add  'Copy'  button  code. 

MsgBox  "Add  'Copy'  butter:  code." 

Case  "Paste" 

'ToDo:  Add  'Paste'  button  code. 

MsgBox  "Add  'Paste'  but  too, 

Case  "Bold" 

'ToDo:  Add  'Bold'  button  code. 

MsgBox  "Add  'Bold'  button  code." 
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Case  "Italic" 

MsgBox  "Add  '  Italic '  but  to::  code. " 

Case  "Underline" 

MsgBox  "Add  'Underline'  b.;ttc&  code." 
Case  "Align  Left" 

MsgBox  "Add  'Align  Lei%*  tor.  code." 
Case  "Center" 

MsgBox  "Add  'Center'  button  code." 

Case  "Align  Right" 

MsgBox  "Add  'Align  Right'  but~o:i  code." 
End  Select 
End  Sub 

Private  Sub  Sheetl_GotFocus ( ) 

End  Sub 

Private  Sub  save_Click() 


'ToDo:  Add  'Italic'  button  code. 


'ToDo:  Add  'Underline'  button  code. 


'ToDo:  Add  'Align  Left'  button  code. 


'ToDo:  Add  'Center'  button  code. 


'ToDo:  Add  'Align  Right'  button  code. 


'  transfer  data  to  excel 


If  Excel. Value  =  True  And  Processed  -  Troo  rhen 

Set  xlApp  =  CreateObject( "Excel. Application" ) 

xlApp .Visible  -  True 

Set  xlbook  -  xlApp .Workbooks . Add 

Set  xlSheetl  =  xlbook. Worksheets  (  "Sh-..*etl " ) 

Set  xlSheet2  =  xlbook. Worksheets < " Sheet 2 " ) 


ProgressBar3  .Max  =  datRespRS .  RecorcLseT  .  RecordCount  -  1 
For  n  =  0  To  da tRespRS. Recordset .Reco recount  -  1 

For  i  =  0  To  205 

singleRowl (i)  =  Matrix! (n,  ij 
Next  i 

For  i  =  0  To  100 

singleRow2 (i)  s  MatrixS (t,  i) 

Next  i 


xlApp. Sheets ("sheetl" ) .Range (xlApp. Ce: 2s (n  +  1,  1) .Address,  _ 

xlApp. Cells  (n  +  1,  UBoundt singleRowl  :■)  .Address)  .Value  =  '  singleRowl 


xlApp . Sheets ( " sheet 2 " ) . Range ( xlApp . Cel 1 s { n  +  1,  1) .Address, 

xlApp. Cells  (n  +  1,  UBound{sir.gieRovv2  j  }  .Address)  .Value  =  singleRow2 


ProgressBar3. Value  =  n 
Next  n 
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End  If 


transfer  data  to  ASCII  File 


If  ASCII. Value  =  True  And  Processed  =  Tr;.e  Then 


Dim  fso,  txtfile 

Set  fso  =  CreateObject ( "Scripting. ?i_eSvstemObject" ) 

Set  txtfile  =  fso.CreateTextFile ( MC : \My  Documents\testfile.txt",  True) 


ProgressBar3  .Max  =  datRespHS. Recordset .RecordCount  -  1 


For  n  =  0  To  da tRespRS. Recordset .RecordCount  -  1 

For  i  =  0  To  205 

txtOut  =  Matrixl(n,  i)  + 
txtfile. Write  (txtOut) 

Next  i 

For  i  =  3  To  datQuestRS . Recordse \ . -VacordCount  -  204  'skip  first  three  lines 
txtOut  =  Matrix2 (n,  i)  ■  " ' 
txtfile. Write  (txtOut) 

Next  i 


txtf ile . WriteLine  (Matri x2(n,  1  -  D)  'last  line  in  row  gets 

'a  newline  character 
'vice  a  comma 


'to  optimize,  make  output  line 
'length  as  close  to  255  characters 
'as  possible 


ProgressBar3 .Value  =  n 
Next  n 

txtf ile. Close 
End  If 

End  Sub 
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APPENDIX  D.  MCERC  USER’S  MANUAL 


Getting  Started 

Please  read  this  manual  carefully  before  attempting  to  use  this  application. 

The  MCERC  application  has  been  specifically  tailored  for  Survey  Management  of 
the  Marine  Corps  Exit  and  Retention  Censuses  (MCERC)  using  Microsoft  Access™  for 
the  survey  instrument  database  and  Cognos  Powerplay™  for  analysis  of  survey  response 
data.  This  manual  provides  installation  procedures  to  get  started  with  MCERC,  use  the 
MCERC  survey  instrument  database,  and  convert  response  data  into  an  appropriate 
format  for  analysis  in  Powerplay.  Comprehensive  procedures  for  using  Powerplay  are 
available  as  an  integrated  help  function  when  using  Powerplay. 

Menu-driven  selections  are  available  to  perform  queries,  data  entry,  or  generate 
reports.  Menu  selections  in  this  manual  are  in  boldface  while  menu  selections  for 
Microsoft  Access™  and  Windows  are  boldface  italics  (the  first  letter  may  be  underlined). 
Filenames  are  underlined. 

Installation  Procedures 

1 .  Place  the  MCERC  disk  in  drive  A:\ 

2.  Copy  the  files  MCERC.exe  and  MCERC.mdb.  to  the  folder  named  “My 
Documents”  in  the  C:\  drive. 

3.  Follow  installation  procedures  that  come  with  the  CD  for  Cognos  Powerplay, 
ensuring  the  program  files  are  installed  in  the 

C:\Program  Files\Cognos\PowerPlay  6.5  directory.  Select  all  components. 

Using  MCERC 

1 .  Select  Start,  Programs,  Microsoft  Access. 

2.  Click  File,  Open. 

3.  Select  the  file  named  MCERC.exe  and  click  Open. 

4.  The  main  menu  will  automatically  appear. 

5.  From  here  you  can: 

a)  go  to  the  database  to  enter  survey  instrument  data,  conduct  a  query,  or 
view  and/or  print  survey  codebooks.  NOTE:  See  the  Menu  Selections  section  for  a 
detailed  explanation  of  each  menu  selection. 

b)  go  to  Cognos  Powerplay  for  analyzing  data  (already  formatted  for  analysis) 
or  to  Cognos  Transformer  to  build  a  Powercube  (format  data  for  Powerplay  analysis) 
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c)  transform  a  data  set  into  a  matrix  which  can  then  be  formatted  by  Transformer 
for  Powerplay. 


Survey  Database  functions 

1.  Select  Manage  Surveys  from  the  Main  Menu.  This  leads  to  a  menu  screen  with  the 
choices  Make  New  Surveys  and  Versions,  View/Print  Survey  Instrument 
Information,  Analyze  Survey  Data,  and  Exit  MCERC.  Help  Procedures  for  Access  are 
available  by  selecting  Help ,  Contents  and  Index  from  the  main  toolbar  or  the  Help  icon  (a 
“?”  inside  a  box)  and  entering  the  subject  or  topic  on  which  you  need  help. 

>New  Surveys 

To  place  a  new  survey  or  a  new  version  of  a  survey  into  MCERC,  select  Make 
New  Surveys  and  Versions.  This  leads  to  a  menu  with  the  options  to  Create  a  New 
Version  of  an  Existing  Survey,  Create  the  first  Version  of  a  New  Survey,  Return  to 
the  Main  Menu,  or  Exit  MCERC. 

To  place  a  new  survey  into  MCERC,  select  Create  the  first  Version  of  a  New 
Survey.  This  leads  to  a  survey  data  entry  form.  On  this  form,  enter  the  Survey  Name 
where  indicated.  This  will  automatically  be  designated  as  Version  "1"  for  this  survey 
name.  It  is  highly  recommended  that  a  short  description  of  the  general  purpose  and 
intentions  of  this  survey  be  entered.  When  entering  future  versions,  this  description  will 
still  apply,  but  there  is  a  version  description  that  allows  you  to  briefly  describe  the 
reason/logic  behind  the  version.  The  name  of  the  person  responsible  for  the  survey,  or  a 
survey  developer  responsible  for  the  design  of  the  survey  should  be  entered  in  the 
"Manager"  block. 

Before  a  survey  can  exist,  there  must  be  a  question  associated  with  it.  If  MCERC 
already  has  a  question  that  you  want  on  this  survey,  you  may  choose  it  from  the  list.  The 
sequence  for  the  question  may  be  chosen  here,  but  as  more  questions  are  added,  re¬ 
sequencing  them  may  be  done.  The  default  value  for  sequence  is  10.  It  is  recommended 
that  sequence  values  are  given  in  multiples  of  10,  giving  the  possibility  to  easily  insert 
other  questions  later  (before  the  survey  is  fielded!)  without  having  to  re-sequence  all  of 
them  again.  Giving  the  inserted  question  a  sequence  value  between  the  sequence  values  of 
two  other  questions  does  this 

If  the  question  is  conditional,  i.e.,  dependent  upon  another  question  or 
demographic  factor  of  the  respondent,  you  may  state  the  condition.  For  example,  if  only 
married  respondents  should  answer  a  question,  you  may  enter  "Married  Only"  or  some 
other  phrase  to  describe  the  condition. 

If  MCERC  does  not  have  a  question  already  for  this  survey,  you  may  create  one  by 
selecting  the  "Create  New  Question"  button.  The  procedure  for  entering  a  new  question 
will  be  described  later.  Once  the  new  question  is  created,  you  will  be  returned  to  the  New 
Survey  form.  Click  in  the  list  of  questions  or  the  scroll  bar  and  find  the  question  you  just 
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created.  It  will  be  in  alphabetical  sequence  within  the  list.  Select  the  question,  assign  it  a 
sequence,  and  if  applicable,  a  condition. 

If  MCERC  has  a  question  for  this  survey,  but  you  want  to  modify  the  question, 
select  "Make  a  new  Version  of  an  Existing  Question".  Then  choose  from  the  list  the 
question  you  want  to  modify.  It  will  automatically  become  the  next  consecutive  version 
number  for  that  question.  The  rest  of  the  procedure  for  modifying  a  question  will  be 
described  later.  Once  you  have  made  the  modifications  (i.e.,  made  a  new  question 
version),  you  will  be  returned  to  the  New  Survey  form.  Click  in  the  list  of  questions  or  the 
scroll  bar  and  find  the  question  you  just  created.  It  will  be  in  alphabetical  sequence  within 
the  list.  Select  the  question,  assign  it  a  sequence,  and  if  applicable,  a  condition. 

>New  VERSIONS  of  Surveys 

To  place  a  new  version  of  a  survey  into  MCERC,  again  select  Make  New  Surveys 
and  Versions.  Then  choose  Create  a  New  Version  of  an  Existing  Survey.  This  leads 
to  a  data  entry  form  for  the  next  version  of  a  survey.  Select  the  survey  from  the  list  that 
you  desire  to  make  another  version  for.  This  automatically  sets  the  next  consecutive 
version  number.  It  will  display  the  survey  description  for  that  survey  that  was  entered  the 
first  time  a  survey  by  that  name,  with  that  purpose  was  entered.  It  is  highly  recommended 
that  a  brief  description  of  the  version,  i.e.,  a  memorandum  noting  the  general  differences 
be  entered  in  the  version  description  field.  The  name  of  the  person  responsible  for  this 
version  of  survey,  or  a  survey  developer  responsible  for  the  design  of  the  version  should 
be  entered  in  the  "Manager"  block. 

Before  a  version  of  a  survey  can  exist,  there  must  be  a  question  associated  with  it.  Refer 
to  the  New  Survey  procedures  above,  as  the  procedures  for  placing  questions  on  a  new 
version  are  identical  to  placing  questions  on  a  new  survey. 

>New  Questions  for  New  Surveys  or  Versions  of  Surveys 

To  design  a  new  question  for  a  new  survey  or  survey  version,  select  the  Create 
New  Question  command  button  from  the  form  as  described  under  the  New  Survey 
section.  Enter  the  question  name  (automatically  version  1),  and  the  description  of  the 
question  to  document  the  information  you  are  attempting  to  collect  with  this  variable. 
Then  enter  the  actual  question,  followed  by  the  format  (single,  multiple,  write-in,  etc.). 
Then  select  a  choice  set  from  the  drop  box.  If  you  want  to  make  a  new  choice  set,  select 
the  New  Choice  Set  button.  This  allows  you  to  name  a  new  Choice  Set,  describe  it,  and 
define  as  many  choices  as  you  want  for  respondents  to  choose  from.  You  must  sequence 
the  choices  as  you  want  them  to  appear.  When  the  Choices  are  all  entered  for  a  Choice 
Set,  close  the  form  by  clicking  on  the  "x"  in  the  upper  right  comer.  This  takes  you  back  to 
the  form  for  making  a  new  question.  Select  the  Choice  Set  name  you  just  defined.  Then 
press  enter  (keyboard)  to  clear  the  question  form.  Click  the  "x"  in  the  upper  comer  of  this 
form.  This  takes  you  back  to  the  survey  form.  Select  from  the  list  the  Question  you  just 
created.  Assign  a  sequence  and  a  condition  (if  needed).  Press  enter  to  update  the  database 
and  clear  the  form. 
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Note:  When  defining  Choices,  you  may  enter  any  number  you  like  for  the 
ChoiceNumber.  They  can  be  in  reverse  sequence  if  desired,  and  "0"  may  be  used. 
However,  you  must  enter  the  "0"  even  though  it  appears  in  the  field  already.  Ensure  you 
do  not  repeat  numbers,  and  give  them  sequence  numbers  for  the  order  in  which  you  want 
them  to  appear  to  the  respondent.  (If  you  want  the  first  question  to  have  the  highest  value 
of  5  choices,  give  value  5  a  sequence  of  1,  4  a  sequence  of  2,  etc.) 

>Modify  Questions  for  New  Surveys  or  Versions 

To  modify  a  question  is  to  make  a  new  version  of  it.  The  procedure  is  very  similar 
to  making  a  new  question,  except  you  must  select  the  question  you  wish  to  modify.  When 
you  select  it  from  the  list,  your  new  question  is  automatically  assigned  the  next 
consecutive  version  number.  You  then  assign  the  format,  type  in  the  question,  and  assign 
a  choice  set  in  the  same  manner  as  described  in  the  "New  Questions  for  New  Surveys  or 
Versions  of  Surveys"  section  above.  A  description  of  this  version,  i.e.,  a  short  justification 
of  the  change,  is  highly  recommended. 

>Add  Questions  to  a  Survey  (before  it  is  fielded!) 

To  add  questions  to  a  survey,  select  Add  Questions  to  Working  Copy  of 
Survey.  From  there  you  can  select  questions  in  the  list  one  at  a  time,  click  on  the  survey 
you  are  placing  them  on,  assign  a  sequence,  and  a  condition. 

>View/Print  Survey  Instrument  Information 

To  View  or  Print  a  copy  of  a  codebook  for  a  survey,  select  View/Print  Survey 
Instrument  Information  from  the  menu.  A  parameter  box  will  prompt  you  for  the 
survey  name,  and  then  the  version  number,  so  you  must  know  this  information.  Once 
entered,  the  codebook  report  will  be  generated  on  the  screen.  To  print  it,  simply  select  the 
printer  icon  on  the  toolbar,  or  select  File,  Print. 

To  View  or  Print  a  listing  of  all  available  Choice  Sets  in  MCERC,  Select 
View/Print  Choice  Set  Listing  from  the  menu. 

Data  Analysis  functions 

2.  From  the  Main  Menu,  there  are  3  choices  related  to  Data  Analysis.  The  data  received 
for  MCERC  must  be  manipulated  into  an  appropriate  matrix  before  analysis  of  the 
responses  can  be  done.  Once  this  is  done,  the  Cognos  Powerplay  analysis  software  can  be 
used  to  model  and  anlyze  the  data. 

>Converting  Data  into  a  Response  Matrix 

To  convert  response  data  into  a  response  matrix,  you  must  first  ensure  the 
response  data  file  you  receive  is  located  in  the  C:\Windows\Temp\  directory  and  the  file  is 
appropriately  named  Responses.mdb  (Microsoft  Access  file).  This  file  will  consist  of  four 
fields  (SSN,  DateTaken,  QuestionName,  and  QuestionAns)  containing  the  last  four  digits 
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of  the  social  security  number,  the  date/time  the  survey  was  taken,  the  question  identifier, 
and  the  response  choice  (answer)  to  the  question  for  every  response  to  every  question  of 
the  dataset  covered  by  the  file. 

Select  the  Create  Response  Matrix  button  from  the  Main  menu.  This  leads  to  a 
screen  for  converting  the  data.  It  may  take  a  few  minutes  for  this  screen  to  appear 
because  the  program  must  read  every  record  of  the  data  file  first.  To  create  the  matrix, 
press  the  Process  button.  This  will  take  several  minutes  as  the  program  sifts  through  the 
data  file  and  arranges  the  data  into  a  matrix. 

The  program  saves  the  matrix  either  to  a  text  based,  comma-delimited  file  named 
testfile.txt  or  to  a  Microsoft  Excel  file  which  you  may  save  to  a  name  and  location  of  your 
choice.  After  the  program  has  converted  the  data,  you  will  choose  the  format  you  desire 
by  clicking  the  appropriate  button  (ASCII  or  Excel)  and  pressing  Save.  Once  saved,  this 
file  may  be  used  by  Cognos  Powerplay,  or  may  be  imported  into  another  statistical 
analysis  application  such  as  SAS™  or  SPSS™.  Close  the  data  conversion  program  by 
selecting  the  "x"  in  the  top  right  comer. 

>Open  Powerplay  Transformer  to  build  a  Powercube 

To  open  Powerplay  Transformer,  you  may  select  it  from  the  main  menu.  Use  the 
parameters  you  desire  to  analyze  to  create  a  Powercube  design,  and  follow  instructions 
found  in  the  Help  menu.  Once  you  have  created  a  Powercube,  you  can  go  straight  to 
Powerplay  from  Transformer  to  analyze  the  cube  you  just  made.  There  is  an  alternate 
method  to  open  Transformer  from  the  MCERC  database  screens. 

>Open  Powerplay  to  Analyze  an  existing  Powercube. 

To  go  straight  to  Powerplay,  select  it  from  the  main  menu.  You  may  also  select  it 
from  the  MCERC  database  screen  by  selecting  Analyze  Survey  Data.  You  may  want  to 
go  straight  to  Powerplay  when  you  have  any  Powercubes  already  built  and  desire  to  use 
them  to  create  more  Powerplay  reports.  Use  the  Help  menu  of  Powerplay  to  guide  you  in 
its  use. 

Backup  and  Recovery  Procedures 

It  is  highly  recommended  that  a  backup  disk  be  maintained  to  preserve  all  data 
entered  in  MCERC.  To  smoothly  accomplish  a  backup  procedure,  it  is  recommended  you 
use  a  ZIP  disk  or  other  external  storage  device.  Copy  the  MCERC.mdb  file  to  it 
frequently  when  entering  data. 

To  restore  MCERC  in  the  event  of  data  loss  or  corruption,  simply  copy  to  files 
back  from  your  external  storage  to  the  directory  where  you  originally  installed  MCERC. 
Providing  proper  Backups  have  been  performed,  data  loss  will  be  kept  to  a  minimum. 
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